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SPECIFICATION 

5 TO ALL WHOM IT HAY CONCERN: 

C Be it known that we: Robert Filepp, a citizen of the United 
Estates of America, residing at 237 Baltusrol Ave., Springfield, N.J. 

if r=i 

igi07081; Michael L. Gordon, a citizen of the United States of America, 
presiding at 34 Hickory Hill Drive, Dobbs Ferry, N.Y. 10522; Alexander 
10 ! ^W. Bidwell, a citizen of the United States of America, residing at 248 
-^East 7th Street, New York, N.Y. 10009, Allan M. Wolf, a citizen of 
2 the United States of America, residing at 127 Fieldcrest Drive, 
£;Ridgefield, Conn. 06877; Francis C. Young, a citizen of the United 
States of America, residing at 35 Maple Shade Drive, Pearl River, N.Y. 
15 10956; Duane Tiemann, a citizen of the United States of America, 
residing at, 50 Orchard Drive, Ossining, N.Y. 10562; Kenneth H. 
Appleman, a citizen of the United States of America, residing at, 96 
Holland Ave., White Plains, N.Y. 10603, and Sam Meo, a citizen of the 
United States of America, residing at, 108 Perry Street, New York, 
20 N.Y. 10014, did make a certain invention entitled METHOD FOR STORING 
DATA IN AN INTERACTIVE COMPUTER NETWORK, a specification of which is 
as follows: 
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METHOD FOR STORING DATA IN 
AN INTERACTIVE COMPUTER NETWORK 





J} RELATED APPLICATIONS 

This is a division of a^^icgtig^ serial number 388,156 filed 
July 28, 1989, which issued *Jafttta*y , 1994, as U.S. patent number 
S~,3<f7/6$2~'' application 388; 156 being a continuation ^i^jpa^t of 
application serial number 328,790, filed March 23, 1989^, which itself 
was a continuation in part of application serial number 219,931, filed 



4i July 15, 1988. 



BACKGROUND OP THE INVENTION 



FIELD OF USE 

This invention relates generarSy^to a method for storing data m 
7a distributed processing, interactive -computer network intended to 
f*brovid€M very large numbers of simultaneous users; e.g» millions, 
an interactive service having lar 9 e Hungers; 
^ousantffe, of applications which ^Include pre-ereated, interactive 
v €e?ct/gr^phic sessions; and more particularly, to a method for storing 
data us^l^ir^ generating such applications, the. method featuring steps 
for est^blishang^data stores, the stores including first store 
portion^ maintained during data usage sessions and se&ond store 
portion^ftoaintained during and between data usage sessions, the method 
also f eajfuring steps for associating storage control parameters with 
the data^ steps for supplying data^tq the stores^" in excess- of store 
capacity F* and steps for deleting .data -.from the— stores on a 
least-recently-used basis, so that data is retained at the stores 
dependent on the storage control parameters and data usage experience. 

PRIOR ART 

Interactive computer networks are not new. Traditionally they 
have included conventional, hierarchical architectures wherein a 
central, host computer responds to the information requests of 
multiple users. An illustration would be a time-sharing network in 
which multiple users, each at a remote terminal, log onto a host that 
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provides data and software resource for sequentially receding user 
data processing requests, executing them and supplying respohses^back 
to the users. 

While such networks have been successful in making the processing 
power of large computers available to many users, problems have 
existed with them* For example, in such networks, the host has been 
required to satisfy all the user data processing requests. As a 
result, processing bottlenecks arise at the host that cause network 
slowdowns and compel expansion in computing resources; i*e., bigger 
and more complex computer facilities, where response times are sought 
to be held low in the face of increasing user populations. 

Host size and complexity, however, are liabilities for 
interactive networks recently introduced to offer large numbers of the 
public access to transactional services such as home shopping, 
banking, and investment maintenance, as well as inf ormational_services 
concerning entertainment, business and personal matters, 

can be appreciated, commercial interactive networks will have 
to preside attractive services at low cost and with minimal response 
times-... .in order to be successful. Unlike military and governmental 
networks where, because of the compulsory nature of the service 
performed, costs, content and efficiency are of secondary concern, in 
commexr^ial services, since use is predominantly elective, and paid for 
by tti|J consumer, costs will have to be held low, content made 
interesting and response times reduced in order to attract and hold 
both iMers who would subscribe to the service and merchandisers who 
would rely on it as a channel of distribution for their goods and 
services. Accordingly, and as will be appreciated, the ability of the 
network to rapidly satisfy large numbers of user requests with minimal 
resources is fundamental to the ultimate success of the network. 

As pointed out in our parent application, serial number 388,156 
filed July 28, 1989, now issued as U.S. patent number , 
breakthrough performance improvement, essential to the feasibility of 
broad-based, interactive services can be realized by storing 
application data local to the user sites and relying on the user site 
computing resources to manage the interactive session. As more fully 
described in our parent application, by locating application data 



closer to the user, for example, at the user terminal configured as 
a reception system and/or a concentrator facility hierarchically 
disposed between the reception system and the service host , 1 ine 
traffic and associated response time that would otherwise be required 
to retrieve data from a conventional, time-share host can be 
substantially reduced. Further, since the host and concentrator 
computers of the reception-system based systems we described can be 
configured as server facilities, they can be provided substantially 
less expensively than conventionally time-share hosts, thereby, 
reducing the capital and operating costs required for the service. 

However, formulating storage facilities for use in such a network 
is not without significant problems. As will be appreciated, the 
amount of storage capacity available at conventional user sites, and 
for that matter, concentrator facilities, is limited. Accordingly, 
because c*€ capacity limitations, it would not be physically and 
economically practical to attempt to store the entire service database 
at the reception system or concentrator sites. Further, even if 
storage capacity sufficient to accommodate substantial portions, if 
not all, *t>f the service database could be provided, the need to 
maintain $j$e application data current would foreclose storing all data 
locally ot at the concentrator. As will be appreciated, the data for 
numerous applicatons of a successful interactive service must remain 
current f^ir the service to be commercially viable. News stories, 

; !ass 

stock quotes, prices of goods, as well as items like airline and 

entertainment seating and scheduling are all time sensitive and must 

be regularly updated to avoid inconvenience and potential legal 

liability. Accordingly, even if all data could be provided locally, 

it would unwise and objectionable to do so. 
A 

SUMMARY OF INVENTION 

Accordingly, it is an object of this invention to provide a 
method for storing data in an interactive-service network. 

It is another object of this invention to provide a method for 
storing data in an interactive-service network, which method reduces 
communication line traffic required to support the service at user 
sites. 
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It is still another object of this invention to provide a method 
for storing data in an interactive-service network, which method 
allows adequate amounts of data to be stored in limited-capacity 
storage facilities. 

It is yet another object of this invention to provide a method 
for storing data in an interactive-service network, which method 
allows for maintaining currency of the data used to present 
applications. 

It is a again a further object of this invention to provide a 
method for storing data in an interactive-service network which method 
automatically configures the data stores to include data tailored to 
the service usage experience. 

Briefly, the method for storing data in accordance with this 
invention achieves the above-noted and other objects by featuring 
steps f Disestablishing data stores of prescribed capacities within the 
network -fyom which data may be obtained for generating the service 
applications during user sessions. Further, the method features steps 
for assorting storage control parameters with the application data 
to be stc£§ed and supplying data to the respective stores in excess of 
their reject ive capacities. Yet further, the method features steps 
for retaining data at the stores based on the respective prescribed 
storage gontrol parameters and the date-usage experience at the 
respective stores. 

In Jceordance with the invention, data stores are established 
within thj service network, preferably at least at the user reception 
system, and, if provided, also at network concentrator facilities 
hierarchically located between the reception system and the network 
host. The size of the respective stores depends on the available 
resources; i.e., RAM and disk memory, and is allocated between a 
temporary cache and variable-content permanent stage, the cache being 
provided at available RAM and a fixed disk file, and the stage being 
configured as a variable-content, fixed disk file. In accordance with 
the invention, data stored during a data-use session; e.g., a user 
interactive session, is stored at the cache distributed between RAM 
and the cache disk file, while data retained between data-use sessions 
is stored at the stage permanent disk file. 



As a further feature of the invention, data is supplied to the 
respective stores in excess of their respective capacities, and in 
preferred form excess data is deleted in accordance with a least- 
recently-used criterion and storage candidacy conditions ascribed to 
the data. Still further, in preferred form a version storage control 
parameter may also be applied. 

In operation, as data is supplied to the store; for example, a 
reception system store during a user interactive session, data is 
retained at the store based on the available cache space within the 
store; i.e., reception system available RAM and designated disk file. 
Particularly, data items designated by a data identification number 
are placed on a list of recently called data items, the most recently 
called items being at the top of the list. As new data is called, it 
pushes previously called data down on the list, with the result that 
a data item pushed below the list capacity forfeits its presence on 
the lis€§if not recalled before being pushed off. If data is recalled 
during a^; session, it once more is promoted to the top of the data 
list, i^t the end of a session, data items at the cache are written 
to a st^je least-recently-used list, the stage retaining data items 
between^ ess ions in the same fashion the cache retains data during a 
session.! 5 The result is, over a series of sessions, the stage 
automatically configures itself; i.e. / self -configures, with the data 
most offtfen called. And, as will be appreciated, where the most 
frequently called data is retained, the efficiency of the limited 
capacity^ store to reduce response time is maximized; i.e., need for 
line data requests is minimized by having data tailored to the user 
readily available. 

Also in accordance with the invention, to insure currency is 
maintained for time-sensitive data; as for example, data relating to 
news, pricing, availability, etc., storage candidacy and version 
control parameters are impressed on the data to avoid storage of data 
considered too sensitive to be maintained on a least-recently-used 
basis alone. In preferred form, a range of storage candidacy values 
are provided and ascribed to the data that dictate whether the 
respective data can be stored beyond the user session or between user 
sessions. In this regard, multiple storage qualifying categories can 
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be established with a combination of control parameters concerning 
data version, storage candidacy value and application of the least- 
recently-used criterion above described. 

Yet further, in preferred form, the application data is organized 
as objects having a header with one or more data segments, the header 
being formulated to include the data identification, storage 
candidacy, and version storage control parameters. Still further, in 
accordance with the preferred form, the storage method may be applied 
to all levels of storage in the interactive-service network; i.e., 
reception system, concentrator facility and host. 

DESCRIPTION OF THE DRAWINGS 

The above and further objects, features and advantages of the 
invention will become clear from the following more detailed 
description when read with reference to the accompanying drawings in 

'ass 

which: 3 gj 

FIG**: ^ i s a block diagram of the interactive computer network in 
which tlje data-storage method of the present invention may be 
employed ]& 

FIGj^2 is a schematic diagram of the network illustrated in FIG. 

i; 

FIG^t 3a and 3b are plan views of a display screen for a user 
receptiopn system employed in a network in which the data-storage 
method oiPthe P re ^^ invention may be practiced; 

FIGffc 4a, 4b^ 4c aftd— *d- are schematic drawings that illustrate 
the structure of objects, and object segments that may be used in a 
network in which the data-storage method of the present invention may 
be employed; 

tf-IG-r-Sa—is a schematic diagram that illustrates the configuration 
of the page templatex^bject which might be used for presentation of 
an application in a network in which the data-storage method of the 
present invention may be practiced; 

FIG. 5b is a schematic di>agr(am that illustrates page composition 
which might be used for presentation of applications in a network in 
which the data-storage method of the present invention may be 
practiced; \^ 




FIG. 6 is a schematic diagram that illustrates the protocol which 
might be used by a reception system for supporting applications in a 
network in w£ir6h the da£a-storage method of the present invention may 
be practiced; 

FIG. /T is a schematic diagram that illustrates major layers for 
a reception system which might be used for supporting applications in 
a network in which the data-storage method of the present invention 

may be practiced; 

Q? 

FIG. / is a block diagram that illustrates native code modules 

A 

for a reception system which might be used for supporting applications 
in a network in which the data-storage method of the present invention 
may be practiced; 

Eiq._9__i s^a schematic diag ram-t1xair~i^u^tr^tes an "exampfre-o^-a^ 
partitioned application to be processed by a reception syste^which 
might b|0 used for supporting applications in a network^i/i^which the 
data-storage method of the present invention may ^be^practiced; 

Flfu 10 illustrates generation of a page^with a page processing 
table for a reception system which might be used for supporting 
applications in a network in vrt^h^the data-storage method of the 
presentoinvention may be practiced; 

Fife. 11 is a flow^iagram for an aspect of the navigation method 
of a reception sy^t^m which might be used for supporting applications 
in a network iriwhich the data-storage method of the present invention 
may be |^£cticed^ 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

GENERAL SYSTEM DESCRIPTION 

FIGS. 1 and 2 show a network in which the method of the present 
invention for storing data might be used. As seen the network, 
designated 10.,^ includes a plurality of reception units within a 
reception layer 401 for displaying information and providing 
transactional services* In this arrangement, many users each access 
network 10 with a conventional personal computer; e.g., one of the IBM 
or IBM-compatible type, which has been provided with application 
software to constitute a reception system (RS) 400. 

As seen in FIG. 1, interactive network 10 uses a layered 
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structure that includes an information layer 100, a switch/file server 
layer 200, and cache/concentrator layer 300 as well as reception layer 
401. This structure maintains active application databases and 
delivers requested parts of the .databases on demand to the plurality 
of RSs 400, shown in FIG* 2. As seen in FIG, 2, cache/ concentrator 
layer 300 includes a plurality of cache/concentrator units 302, each 
or which serve a plurality of RS 400 units over lines 301. 
Additionally, switch/file server layer 200 is seen to include a server 
unit 205 connected to multiple cache/concentrator units 302 over lines 
201. Still further, server unit 205 is seen to be connected to 
information layer 100 and its various elements, which act as means for 
producing, supplying and maintaining the network databases and other 
information necessary to support network 10. Continuing, switch/filer 
layer 200 is also seen to include gateway systems 210 connected to 
server #05. Gateways 210 couple layer 200 to other sources of 
information and data; e.g., other computer systems. As will be 
appreciated by those skilled in the art, layer 200, like layers 401 
and 300iXcould also include multiple servers, gateways and information 
layers ^jHi the event even larger numbers of users were sought to be 
served.;.* 

Cofttirtuing with reference to FIG. 2, in preferred form, each RS 
400 is :j?een to include a personal computer 405 having a CPU 410 
includi^ a microprocessor (as for example, one of the types made by 
INTEL Corporation ii\ its X x 86 family of microprocessors), companion 
RAM andyglOM memory and^other associated elements, such as monitor 412 
with screen 414 and a ke^(board 424. Further, personal computer 405 
may also include one or two floppy disk drives 416 for receiving 
diskettes 426 containing application software used to support the 
interactive service and facilitate the interactive sessions with 
network 10. Additionally, personal computer 405 would include 
operating systems software; e.g., ^S-DOS, supplied on diskettes 428 
suitable for the personal computer bei^ig used. Personal computer 405 
still further may also include a hard-disk drive 420 for storing the 
application software and operating system software which may be 
transferred from diskettes 426 and 428 respectfully. 

Once so configured, each RS 400 provide^ a common interface to 
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othe r elem^rybs of interactive compu ter /network — l&t — a — eemmen 
AnvT^onment foK appliTea-tion process inqrr^and a common protocol for 



'T tegr-applig ^ independent, uk Llm^srsonal^ 

computer brand ucod? — RS^jMJ^^ 

. prepared r thereby render irrfotS^ ^ — ±fvfee^prefeable_M_^ 

RS 400 formulated in this fashion is capable of communication 
with the host system to receive information containing either of two 
types of data, namely objects and messages. Objects have a uniform, 
self -defining format known to RS 400, and include data types, such as 
interpretable programs and presentation data for display at monitor 
screen 414 of the user's personal computer 405. Applications 
presented at RS 400 are partitioned into objects which represent the 
minimal3anits available from the higher levels of interactive network 
10 or £S 400. In this arrangement , each appl icat ion partition 
typically represents one screen or a partial screen of information, 
including fields filled with data used in transactions with network 
10. Eacjti such screen, commonly called a page, is represented by its 
parts aft& is described in a page template object, discussed below. 

Applications, having been partitioned into minimal units, are 
available from higher elements of network 10 or RS 400, and are 

retrieved on demand by RS 400 for interpretive execution. Thus, not 

■SF* 

all partitions of a partitioned application need be resident at RS 400 
to prob^ss a selected partition, thereby raising the storage 
efficiency of the user's RS 400 and minimizing response time. Each 
application partition is an independent, self-contained unit and can 
operate correctly by itself. Each partition may refer to other 
partitions either statically or dynamically. Static references are 
built into the partitioned application, while dynamic references are 
created from the execution of program logic using a set of parameters, 
such as user demographics or locale. Pa-rti^onsr^ay^^^ — 
~f-— ^tr^ — ^-f^p^ing in re sponse — to user created events, or by 
selecrt^ng~"a"'key wor<T ^yf--^he-^a rt i tinne d appl i cat^TT^TgT^" JUMP" or 
" INDEX , ">Hsf"fg^ h^lnw) f which provides random ar . ce &s — fee — ai~l 



services repre^n^ed-tey^partl^^ 
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Objects provide a means of packaging and distributing partitioned 
applications. As noted, objects make up one or more partitioned 
applications, and are retrieved on demand by a user's RS 400 for 
interpretive execution and selective storage. All objects are 
interpreted by RS 400, thereby enabling applications to be developed 
independently of the personal computer brand used. 

Objects may be nested within one another or referenced by an 
object identifier (object-id) from within their data structure. 
References to objects permit the size of objects to be minimized. 
Further, the time required to display a page is minimized when, in 
accordance with the method of the present invention, referenced 
objects are stored locally at RS 400 (which storage is determined by 
prior usage meeting certain retention criteria to be described more 
fully below) , or have been pre-f etched, or in fact, are already used 
for the^current page. 

Ob^cts carry application program instructions and/or information 
for dismay \t monitor screen 414 of RS 400. Application program 
objects calledVpre-processors and post-processors, set up the 
environiieent for theNiser's interaction with network 10 and respond to 
events created when theN^ser inputs information at keyboard 424 of RS 
400. Su^ch events typical ly\tr igger a program object to be processed, 
causing pn& of the following: sending of transactional information to 
the coapTplications in one layer\f the network 10; the receiving of 
information for use in programs qr^for presentation in application- 
dependent fields on monitor screen*>14; or the requesting of a new 
objects to be processed by RS 400. Such\objects may be part of the 
same application or a completely new application. 

The RS 400 supports a protocol by whichN±he user and the 
partitioned applications communicate. All partitioned applications 
are designed knowing that this protocol will be supporteU^in RS 400. 
Hence, replication of the protocol in each partitioned application is 
avoided, thereby minimizing the size of the partitioned application. 

RS 400 includes a means to communicate with network 10 to 
retrieve objects in response to events occurring at RS 400 and to send 
and receive messages. 

In accordance with the method of the present invention, RS 400 
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includes a means to selectively store objects according to a 
predetermined storage criterion, thus enabling frequently used objects 
to be stored locally at the RS, and causing infrequently used objects 
to forfeit their local storage location. The currency of objects 
stored locally at the RS 400 is verified before use according to the 
object's storage control parameters and the storage criterion in use 
for version checking. 

Selective storage tailors the contents of the RS 400 memory to 
contain objects representing all or significant parts of partitioned 
applications favored by the user. Because selective storage of 
objects is local, response time is reduced for those partitioned 
applications that the user accesses most frequently. 

Since much of the application processing formerly done by a host 
computer in previously known time-sharing networks is now performed 
at the user's RS 400, the higher elements of network 10, particularly 
layer 2&h, has as their primary functions the routing of messages, 
serving r-of objects, and line concentration. The narrowed functional 
load of ;^jthe higher network elements permits many more users to be 
servicedFwithin the same bounds of computer power and I/O capability 
of conventional host-centered architectures. 

Ne^©-Kj$^a provides information on a wide variety of topics, 
including, but not limited to news, industry, financial needs, hobbies 
and cultural interests. Network 10 thus eliminates the need to 
consult Multiple information sources, giving users an efficient and 
timesaviftg overview of subjects that interest them. 

The' transactional features of interactive network 10 saves the 
user time, money, and frustration by reducing time spent traveling, 
standing in line, and communic^ijig with sales personnel. The user 
may, through RS 400, bank, sWid and receive messages, review 
advertising, place orders for is^rchandise, and perform other 
transactions. \ 

In preferred form, network 10 prov^es information, advertising 
and transaction processing services for\ a large number of users 
simultaneously accessing the network via theVublic switched telephone 
network (PSTN) , broadcast, and/or other media with their RS 400 units. 
Services available to the user include display ok information such as 



movie reviews, the latest news, airlines reservations, the purchase 
of items such as retail merchandise and groceries, and quotes and 
buy/sell orders for stacks and bonds. Network 10 provides an 
environment in which a user/\yia RS 400 establishes a session with the 
network and accesses a large nmnber of services. These services are 
specifically constructed applications which as noted are partitioned 
so they may be distributed withoutNundue transmission time, and may 
be processed and selectively stored ori^a user's RS 400 unit. 

SYSTEM CONFIGURATION 

As shown in FIG.l, interactive computer network 10 includes four 
layers: information layer 100, switch and file server layer 200, 
concentrator layer 300, and reception layer 401. 

Information layer 100 Jrandles: (1) the production, storage and 
dissemination of data and^(2) the collection and off-line processing 
of such ^ata from each RS session with the network 10 so as to permit 
the targeting of information and advertising to be presented to users 
and for traditional /business support. 

Switch and fil^e server layer 200 and cache/ concentrator layer 300 
y-jconstitute^a delivery system 20 which delivers requested data 
ption layer 401 and routes data entered by the 
user or gsoll^cted at RSs 400 to the proper application in network 10. 
With rejferefhce to FIG. 2, the information used in a RS 400 either 
resides^pcally at the RS 400, or is available on demand from the 
cache/co&bentrator 300 or the file server 205, via the gateway 210, 
which may be coupled to external providers, or is available from 
information layer'^lOO. 

There are two types of information in the network 10 which are 
utilized by the RS 400: objects and messages. 

Objects include the information requested and utilized by the RS 
400 to permit a user to select specific parts of applications, control 
the flow of information relating to the applications, and to supply 
information to the network. Objects are self -describing structures 
organized in accordance with a specific data object architecture, 
described below. Objects are used to package presentation data and 
program instructions required to support the partitioned applications 
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and advertising presented at a RS 400. Objects are distributed on 
demand throughout interactive network 10. Objects may contain: 
control information; program instructions to set up an application 
processing environment and to process user or network created events; 
information about what is to be displayed and how it is to be 
displayed; references to programs to be interpretively executed; and 
references to other objects, which may be called based upon certain 
conditions or the occurrence of certain events at the user's personal 
computer, resulting in the selection and retrieval of other 
partitioned applications packaged as objects. 

Messages are information provided by the user or the network and 
are used in fields defined within the constructs of an object, and are 
seen on the user's RS monitor 412, or are used for data processing at 
RS 400. Additionally, and as more fully described hereafter, messages 
are the primary means for communication within and without the 
networkjf The format of messages is application dependent. If the 
message llis input by the user, it is formatted by the partitioned 
applicat&on currently being processed on RS 400. Likewise, and with 
referenda to FIG. 2, if the data are provided from a co-application 
databas^residing in delivery system 20, or accessed via gateway 210 
or high function system 110 within the information layer 100, the 
partitioned application currently being processed on RS 400 causes the 
message Jifata to be displayed in fields on the user's display monitor 
as defined by the particular partitioned application. 

Allyftctive objects reside in file server 205. Inactive objects 
or objects in preparation reside in producer system 120. Objects 
recently introduced into delivery system 20 from the producer system 
120 will be available from file server 205, but, may not be available 
on cache/concentrator 302 to which the user's RS 400 has dialed. If 
such objects are requested by the RS 400, the cache/concentrator 302 
automatically requests the objecrt from file server 205. The requested 
object is routed back to the requesting cache/concentrator 302, which 
automatically routes it to the communications line on which the 
request was originally made, from which it is received by the RS 400. 

The RS 400 is the point of application session control because 
it has the ability to select and randomly access objects representing 
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all or part of partitioned applications and their data. RS 400 
processes objects according to information contained therein and 
events created by the user on personal computer 405. 

Applications on network 10 act in concert with the distributed 
5 partitioned applications running on RS 400. Partitioned applications 
constructed as groups of objects and are distributed on demand to a 
user's RS 400. An application partition represents the minimum amount 
of information and program logic needed to present a page or window, 

1. e. portion of a page presented to the user, perform transactions 
0 with the interactive network 10, and perform traditional data 

processing operations, as required, including selecting another 
partitioned application to be processed upon a user generated 
completion event for the current partitioned application. 

In accordance with the invention, objects representing all or 
5 part q€ partitioned applications may be stored in a user's RS 400 if 
the oBfects meet certain criteria, such as being non-volatile, non- 
critical to network integrity, or if they are critical to ensuring 
reasonable response time. Such objects are either provided on 

jssr 

diskettes 426 together with RS 400 system software used during the 
D installation procedure or they are automatically requested by RS 400 
when the user makes selections requiring objects not present in RS 
400 . 5ijr n the l atter case, RS 400 requests from cache/concentrator 
layerlj-300 only the objects necessary to execute the desired 
partitioned application. 
5 Reception system application software 426 in preferred form is 

provided foKJBM and IBM-compatible brands of personal computers 405, 
and all partitioned applications are constructed according to a single 
architecture which^each such RS 400 supports. With reference to FIG. 

2, to access network lo>sa user preferably has a personal computer 405 
D with at least 512K RAM ahd a single disk drive 416. The user 

typically accesses network 10 u^ing a 1,200 or 2,400 bps modem (not 
shown) . To initiate a session withs^e^work 10, objects representing 
the logon application are retrieved fr^m^the user's personal diskette, 
including the RS 400 application softwar^xwhich was previously set 
5 up during a standard installation and enrollment procedures with 
network 10. Once communication between RS 400 andNsache/concentrator 
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layer 300 has been established, the user begins a standard logon 
procedure by inputting\a personal entry code. Once the logon 
procedure is complete, the \ser can begin to access various desired 
services (i.e., partitioned apJp^cat^ns) which provide display of 
requested information and/or transition operations. 

APPLICATIONS AND PAGES 

Applications, i.e. information events, are composed of a 
sequence of one or more pages opened at screen 414 of monitor 412. 
This is better seen with reference to FIG 3a and 3b were a page 255 
is illustrated as might appear at screen 414 of monitor 412. With 
reference to FIG. 3a, each page 255 is formatted with a service 
interface having page partitions 250, 260, 280, and 290 (not to be 
confused with application partitions) . Window page partitions 275, 
well known in the art, are also available and are opened and closed 
conditionally on page 255 upon the occurrence of an event specified 
in the application being run. Each page partition 250, 260, 280 and 
290 arid window 275 is made up of a page element which defines the 
content* of the partition or window. 

E&eh page 255 includes: a header page partition 250, which has 
a page 10 elemenK^associated with it and which typically conveys 
information on thexgpage's topic or sponsor; one or more body page 
partitions 260 and window page partitions 275, each of which is 
associated with a page element which as noted gives the informational 
and transactional content of the page. For example, a page element 
may cofitain presentation data selected as a menu option in the 
previous page, and/or may contain prompts to which a user responds in 
pre-defined fields to execute transactions. As illustrated in FIG. 
3b, the page element associated with\body page partition 260 includes 
display fields 270, 271, 272. A winoow page partition 275 seen in 
FIG. 3a represents the same informational^ and transactional capability 
as a body partition, except greater flexibility is provided for its 
location and size. 

Continuing with reference to FIG. 3a, in accordance with the 
invention, advertising 280 is provided over network 10, like page 
elements, also includes information for display on\page 255, and may 
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be included in any partition of a page. Advertising 280 is presented 
to the user on an individualized basis from queues of advertising 
object identifications (ids) that are constructed off-line by business 
system 130, and sent to file server 205 where they are accessible to 
each RS 400. 

Individualized queues of advertising object ids arey6onstructed 
based upon data collected on the partitioned applications that were 
accessed by a user, and upon events the user generated yin response to 
applications. The data are collected and reported by^lS 400 to a data 
collection co-application in file server 205 for lajter transmission 
to business system 130. In addition to application access and use 
characteristics, a variety of other parameters, such as user 
demographics or postal ZIP code, may be used as targeting criteria. 
From such data, queues of advertising object ids are constructed that 
are targeted to either individual users or to s^/ts of users who fall 
into certain groups according to such parameters. Stated otherwise, 
the advertising presented is individualized to the respective users 
based *Sn characterizations of the respective ufeers as defined by the 
interaction history with the service and such other information as 
user demographics and locale. As will be appreciated by those skilled 
in th^ art, conventional marketing analysis techniques can be employed 
to establish the user characterizations based on the collected 
applid&tion usage data above noted and other information. 

i£Lso with reference to FIG. 3b, the service interface is seen to 



incluc|*» a command region 285 which enables a user to interact with the 
network RS 400 and other elements of network 10, so as to cause such 
operations as navigating from page to page, performing a transaction, 
or obtaining more information about oth^r applications. As shown in 
FIG. 3b, command region 285 includes a ^command bar 290 having a number 
of commands 291-298 which the user ^san execute. The functions of 
commands 291-298 are discussed in greater detail below. 

NETWORK OBJECTS 

As noted above, in conventional time-sharing computer networks, 
the data and program instructions necessary to support user sessions 
are maintained at a central host computer. However, that approach has 
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been found to create processing bottlenecks as greater numbers of 
users are connected to the network; bottlenecks which require 
increases in processing power and complexity; e.g., multiple hosts of 
greater computing capability, if the network is to meet demand. 
Further, such bottlenecks have been found to also slow response time 
as more users are connected to the network and seek to have their 
requests for data processing answered. 

The consequences of the host processing bottlenecking is to 
either compel capital expenditures to expand host processing 
capability, or accept longer response times; i.e., a slower network, 
and risk user dissatisfaction* 

However, even in the case where additional computing power is 
added, and where response tipie is allowed to increase, eventually the 
host- becomes user saturated as more and more users are sought to be 
serSfed by the network. The network described above, however, is 
designed to alleviate the effects of host-centered limitations, and 
extend the network saturation point. This objective is achieved by 
reccing the demand on the host for processing resources by 
structuring the network so that the higher network levels act 
primarily to maintain and supply data and programs to the lower levels 
ofjthe network, particularly RS 400, which acts to manage and sustain 
thil user screen displays. 

^ More particularly, the described network features procedures for 
psygsing the network data and program instructions required to support 
the interactive user sessions into packets, referred to_a§ ofegecta, 
and distributing them into the network where they can be processeS^at 
lower levels, particularly, reception system 400. 

an^accordance with the method of the present invention, the 
screens pirs^ented at the user's monitor are each divided into 
addressable paxt^tions shown in FIG. 3a, and the display text and 
graphics necessary tbvjnake up the partitions, as well as the program 
instructions and control^d^ta necessary to deliver and sustain the 
screens and partitions, are rt>aqjiulated from pre-created objects. 
Further, the objects are structured irr^ccordance with an architecture 
that permits the displayed data to be relbs^table on the screen, and 
to be reusable to make up other screens and ot^fer sessions, either as 
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pre-created and stored se"^sions or interactive sessions, dynamically 
created in response to the u^e^*s requests. 

As shown in FIG. 4c, the network objects are organized as a 
family of objects each of which perform a specific function in support 
of the interactive session. More particularly, i - n accordance « with the , 
prefftrrad f g r 1 ^-^ *" h *> imro w^^ the network object family is seen to 
include 6 members: page format objects 502, page element objects 504, 
window objects 506, program objects 508, advertisement objects 510 and 
page template objects 500. 

Within this family, page format objects 502 are designed to 
define tk\e partitioning 250 to 290 of the monitor screen shown in FIG. 
3a. The p^ge format objects 502 provide a means for pre-defining 
screen partitions and for ensuring a uniform look to the page 
presented on the\reeeption system monitor. They provide the origin; 
i.e., drawing pornts, and dimensions of each page partition and 
differ^t values for presentation commands such as palette and 
background color. \ 

Paiffe format object&\502 are referenced whenever non-window data 
is to fc>4 displayed and as iioted ensure a consistent presentation of 
the pa#g. In addition, pbge format objects 502 assures proper 
tessellation or "tiling" of th^displayed partitions. 

PagD£ element objects 504, o&the other hand, are structured to 
containHthe display data; i.e., text and graphic, to be displayed 
which i^ mapped within screen partitions 250 to 290, and to further 
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provide #ie associated control data and^programs . More specifically, 
the display data is described within the\object as NAPLPS data, and 
includes, PDI, ASCII, Incremental Point and other display encoding 
schemes. Page element objects also control Vhe functionality within 
the screen partition by means of field definition segments 516 and 
program call segments 532, as further describedXin connection with the 
description of such segments hereafter. Page element objects 504 are 
relocatable and may be reused by many pages\ To enable the 
displayable data to be relocated, display data must be created by 
producers in the NAPLPS relative mode. \ 

Continuing with reference to FIG. 4c, window objects 506 include 
the display and control data necessary to support window partitions 



275 best seen ih FIG. 3a. Windows contain display data which overlay 
the base page and control data which supersede the base page control 
data for the underlying screen during the duration of the window. 
Window objects 506\ contain data which is to be displayed or otherwise 
presented to the viewer which is relatively independent from *the rest 
of the page. DisplaV data within windows overlay the base page until 
the window is closed\ Logic associated with the window supersedes 
base page logic for trie duration of the window. When a window is 
opened, the bit map of the area covered by window is saved and most 
logic functions for the\ overlaid page are deactivated. When the 
window is closed, the saved bit map is swapped onto the screen, the 
logic functions associated\with the window are disabled, and prior 
logic functions are reactivated. 

Windows are opened by user or program control. They do not form 
part of the base page. Windows\would typically be opened as a result 
of the 'completion of events specified in program call segments 532. 

Wiftdow objects 506 are very similar in structure to page element 
objects3"504\ The critical difference is that window objects 506 
specif yjtheir own size and absolute screen location by means of a 
partition definition segment 528. \ 

Program objects 508 contain program instructions written in a 
high-lev^l language called TRINTES Basi<2 Object Language, i.e., TBOL, 
described in greater detail hereafter, which may be executed on RS 400 
to support the application. More particularly, program objects 508 
include yjinterpretable program code, executable machine code and 
parameters to be acted upon in conjunction yith the presentation of 
text and graphics to the reception system monitors. 

Program objects 508 may be called for ^execution by means of 
program call segments 532, which specify wherk a program is to be 
executed (event) , what program to execute (program pointer) , and how 
programs should run (parameters) . \ 

Programs are treated as objects to conform tb the open-ended 
design philosophy of the data object architecture (DOA) , allowing the 
dissemination of newly developed programs to bet easily and 
economically performed. As noted above, it is desirable to have as 
many of these program objects staged for execution at or\as close to 
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RS 400 as possible. 

Still further, advertising objects 510 include the text and 
graphics that may be presented at ad partition 28 (r presented on the 
monitor screen as shown in FIG. 3b. / 
5 Finally, the object family includes page/template objects 500. 

Page template objects 500 are designed to define the components of the 
full screen presented to the viewer, particularly, page template 
objects 500 include the entry point to/a screen, the name of the page 
format objects which specify the various partitions a screen will have 
and the page element object t#at contain the display data and 
partitioning parameters for the page. 

Additionally, page template object 500 includes the specific 
program calls required to execute the screens associated with the 
application being presented to the user, and may serve as the means 
for the user to selectively move through; i.e., navigate the pages of 
interest which are associated with various applications. Thus, in 
effect, ;^page template objects 500 constitute the "recipe" for making 
up the qpl^ction of text and graphic information required to make the 
screens^€o be presented to the user. 

Objects 500 to 510 shown in FIG. 4c are themselves made up of 
further ^sub-blocks of information that may be selectively collected 
to define the objects and resulting pages that ultimately constitute 
the application presented to the user in an interactive text and 
graphic ;^ssion . 

Moir# specifically and as shown schematically in FIG. 4a, objects 
500 to 5*0 are predefined, variable length records consisting of a 
fixed length header 551 and one or more self-defining record segments 
552 a list of which is presented in FIG. 4c as segment types 512 to 
540. 

In accordance with this design, and as shown in FIG. 4b, object 
header 551 in preferred form is 18 bytes in length and contains a 
prescribed sequence of information which provides data regarding the 
object's identification, its anticipated use, association to other 
objects, its length and its version and currency. 

More particularly, each of the 18 bytes of object header 551 are 
conventional hexadecimal , 8 bit bytes and are arranged in a fixed 
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pattern to facilitate interpretation by network 10. Particularly, and 
as shown in FIG. 4b, the first byte of header 551; i.e., byte 1, 
identifies the length of thie object ID in hexadecimal. The next six 
bytes; i.e., bytes 2 to 7, are allocated for identifying access 
> control to the object so as to allow creation of closed user groups 
to whom the object (s) is to be provided. As will be appreciated by 
those skilled in the art, the ability to earmark objects in 
anticipation of user requests enables the network to anticipate 
requests and pre-collect objects from large numbers of them maintained 
to render the network more efficient and reduce response time. The 
following 4 bytes of header 551; bytes 8 to 11, are used to identify 
the set of objects to which the subject object belongs. In this 
regard, it will be appreciated that, again, for speed of access and 
efficiency of selection, the objects are arranged in groups or sets 
which are likely to be presented to user sequentially in presenting 
the pag§: sets; i.e., screens that go to make up a session. 

Following identification of the object set, the next byte in 
header si*j51; i.e., byte 12, gives the location of the subject object 
in the 4&t» As will be appreciated here also the identification is 
provided" to facilitate ease of object location and access among the 
many thousands of objects that are maintained to, thereby, render 
their selection and presentation more efficient and speedy. 

Thereafter, the following byte of header 551; i.e., byte 13, 
designates the object type; e.g., page format, page template, page 
element ,>etc. Following identification of the object type, two bytes; 
i.e., by£es 14, 15, are allocated to define the length of the object, 
which may be of whatever length is necessary to supply the data 
necessary, and thereby provides great flexibility for creation of the 
screens. Thereafter, in accordance with the preferred form of the 
invention, a single byte; i.e., byte 16, is allocated to identify the 
storage characteristic for the object; i.e., the criterion which 
establishes at what level in network 10 the object will be stored, and 
the basis upon which it will be updated. At least a portion of this 
byte; i.e, the higher order- nibble (first 4 bits reading from left to 
right) is associated with the last byte; i.e., byte 18, in the header 
which identifies the version of the object, a control used in 
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determining how often in a predetermined period of time the object 
will be updated by the network. 

Following storage characteristic byte 16, header 551 includes a 
byte; i.e., 17, which identifies the number of objects in the set to 
5 which the subject object belongs. Finally, and as noted above, in 
accordance with the invention, header 551 includes a byte; i.e., 18, 
which identifies the version of the object. Particularly the object 
version is a number to establish the control for the update of the 
object that are resident at RS 400. 

As shown in FIG. 4a, and as noted above, in addition to header 
551, the object includes one more of the various segment types shown 
in FIG. 4c. 

Segments 512 to 540 are the basic building blocks of the objects. 
And, as in the case of the object, the segments are also self- 
defining. As will be appreciated by those skilled in the art, by 
making *he segments self -defining, changes in the objects and their 
use in Hie network can be made without changing pre-existing objects. 

As fin the case of objects, the segments have also been provided 
with a Jfpecific structure. Particularly, and as shown in FIG. 4a, 
segment^*! 552 consists of a designation of segment type 553, 
identification of segment length 554, followed by the information 
necessary to implement the segment and its associated object 555; 
e.g., either, control data, display data or program code. 

In iJhis structure, segment type 553 is identified with a one-byte 
hexadecimal code which describes the general function of the segment. 
Thereafter, segment length 554 is identified as a fixed two-byte long 
field which carries the segment length as a hexadecimal number in 
INTEL format; i.e., least significant byte first. Finally, data 
within segments may be identified either by position or keyword, 
depending on the specific requirements of the segment. 
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The structure for\objects is: 
PAGE TEMPLATE OBJECT, 
[<header> (compression descriptor) <page format call> (page element 
call) ... (program call)\... (page element selector) (system table 
call) ... external reference) (keyword/navigation) ...]; 

As noted above, page format objects 502 are designed to define 
the partitioning 250 to 290 \>f monitor screen 414 shown in FIG. 3a. 
PAGE FORMAT OBJECT, 

[<header> (compression descriptor) (page defaults) <partition 
def inition>] ; 

PA^E ELEMENT OBJECT, 
[<header> (compression descriptoir) (presentation data) . . . (program 
call) .41* (custom cursor) ... (custom text) ... (field definition) 
... (^.eld-level program call)\... (custom cursor type 2)... 
(cus tomographic) . . . (field definition type 2) . . . (array definition) 
... ( inventory control ) ] ; 

Pacje element objects, as explaine\i, are structured to contain the 
display ?=data; i.e., text and graphics^, to be presented at screen 
partitions 250 to 290. 

WINDOW OBJECT, 

[<header§* : (compression description) <pairt:ition definition> (page 
element call) (presentation data) — (program call) ... (custom 
cursor) (custom text) ... (custom cursor type 2) ... (custom 

graphic) ... (field definition) ... (field \level program call) ... 
(field definition type 2) ... (array definition) ... (inventory 
control) ] ; 

As noted, window objects include display and control data 
necessary to support window partition at screen 4^4, 

PROGRAM OBJECTS, 
[<header> (compression descriptor) <program data> A.]. 

Program objects, on the other hand, contain program instructions 



written in Kigher- level language which may be executed at RS 400 to 

support the application, 

ADVERTISEMENT OBJECT, 

[<header> (compression descriptor) (presentation data) . . . (program 
5 call) ... (custom cursor) ... (custom text) ... (field definition) 

... (field-level program call) ... (custom cursor type 2)... 

(custom graphic) . . . (field definition type 2) . . . (array definition) 

... ( inventory control ) ]\ 

In accordance with tshe invention, and as can be seen, 
.0 advertisement objects are substantially the same as page element 

objects, with the difference beiKg that, as their name implies, their 

subject matter is selected to concern advertising. 

Continuing, the structure forXthe object segments follows from 

the above description, and is as ctescribed more fully in parent 
5 application serial number 388,156 nowXissued as U.S. patent 

, the Contents of which patent are incorporated herein by reference. 

'ass:: 

^ NETWORK MESSAGES 

I# addition to the network objects, and the display data, control 
data, /§ nd the program instructions they contain as previously 
described, network 10 also exchanges information regarding the support 
of use£, sessions and the maintenance of the network as "messenger" . 
Specifically, messages typically relate to the exchange of information 
associated with initial logon of a reception system 400 to network 10, 
dialogulk between RS 400 and other elements and communications by the 
other network elements amongst themselves. 

To facilitate message, exchange internally, and through gateway 
210 to entities externally to network 10, a protocol termed the "Data 
Interchange Architecture" (DIA) is used to support the transport and 
interpretation of information. More particularly, DIA enables: 
communications between RS 400 units, separation of functions between 
network layers 100, 200, 300 and 401; consistent parsing of data; an 
"open" architecture for network 10; downward compatibility within the 
network; compatibility with standard industry protocols such as the 
IBM System Network Architecture; Open Systems Interconnections 
standard; support of network utility sessions; and standardization of 
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common network and application return codes . 

Thus DIA binds the various components of network 10 into a 
coherent entity by providing a common data stream for communications 
management purposes. DIA provides the ability to route messages 
5 between applications based in IBM System Network Architecture (SNA) , 
(well known in the art, and more fully described in Data and Computer 
Communications , by W. Stallings, Chapter 12, McMillian Publishing, 
Inc. (1985)) and non-SNA reception system applications; e.g. home 
computer applications. Further, DIA provides common data structure 
between applications run at RS 400 units and applications that may be 
run on external computer networks; e.g. Dow Jones Services, accessed 
through gateway 210. As well, DIA provides support for utility 
sessions between backbone applications run within network 10. A more 
detailed description of network messaging in. provided in parent 
application serial number 388,156 now issued^ as U.S. patent ^- _ rT 
, the contents of which patent are incorporated herein by reference. 

OBJECT LANGUAGE 

Irf^accordance with the design of network 10, in order to enable 
the manipulation of the network objects, the application programs 
necessaFy to support the interactive text/graphic sessions are written 
^in a high-level language referred to as "TBOL", (TRINTEX Basic Object 
Languagf^ "TRINTEX" being the former company name of one of the 
assignees of this invention) . TBOL is specifically adapted for 
writing fllhe application programs so that the programs may be compiled 
into a compact data stream that can be interpreted by the application 
software operating in the user personal computer, the application 
software being designed to establish the network Reception System 400 
previously noted and described in more detail hereafter. 

The Reception System application software supports an interactive 
text/graphics sessions by managing objects. As explained above, 
objects specify the format and provide the content; i.e., the text and 
graphics, displayed on the user's screen so as to make up the pages 
£hat constitute the application. As also explained, pages are divided 
/into separate areas called "partitions" by certain objects, while 
/ certain other objects describe windows which can be opened on the 
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pages. Further, still other objects contain TBOL application programs 
which facilitate the data processing necessary to present the pages 
and their associated text and graphics. 

As noted, the object architecture allows logical events to be 
5 specified in the object definitions. An example of a logical event 
is the completion of data entry on a screen; i.e., an application 
page. Logical events are mapped to physical events such as the user 
pressing the <ENTER> key on the keyboard. Other logical events might 
be the initial display of a screen page or the completion of data 
entry in a field. Logical events specified in page and window object 
definitions can be associated with the call of TBOL program objects. 

RS 400 is aware of the occurrence of all physical events during 
the interactive text/graphic sessions. When a physical event such as 
depression of the forward <TAB> key corresponds to a logical event 
such as completion of data entry in a fiel<J, the appropriate TBOL 
prograitg is executed if specified in the object definition. 
Accordingly, the TBOL programs can be thought of as routines which are 
given Control to perform initialization and post-processing 
application logic associated with the fields, partitions arid screens 
at the tpxt/graphic sessions. 

RS ; *fc00 run time environment uses the TBOL programs and their 
high-le%el key-word commands called verbs to provide all the system 
services?* needed to support a text/graphic session, particularly, 
display" Management, user input, local and remote data access. 

TBQJS programs have a structure that includes three sections: a 
header section in which the program name is specified; a data section 
in which the data structure the program will use are defined; and a 
code section in which the program logic is provided composed of one 
or more procedures. More specifically, the code section procedures 
are composed of procedure statements, each of which begins with a TBOL 
key word called a verb. 

The name of a procedure can also be used as the verb in a 
procedure statement exactly as if it were a TBOL key-word verb. This 
feature enables a programmer to extend the language vocabulary to 
include customized application-oriented verb commands. 

Continuing, TBOL programs have a program syntax that includes a 
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series of "identifiers" which are the names and labels assigned to 
programs, procedures, and data structures. 

An identifier may be up to 31 characters long; contain only 
uppercase or lowercase letters A through Z, digits 0 through 9, and/or 
the special character underscore (_J ; and must begin with a letter. 
Included among the system identifiers are: "header section 
identifiers" used in the header section for the program name; "data 
section identifiers" used in the data section for data structure 
names, field names and array names; and finally, "code section 
identifiers" used in the code section for identification of procedure 
names and statement labels. A more detailed description ^^TBgL^is 
provided in parent application serial number 388,156 how issued^ as 
U.S. patent <g~J¥% the contents of which patent are incorporated 

herein by reference. 

P RECEPTION SYSTEM OPERATIC 

RS^iOO of computer system network 10 uses/ software called native 
code modules (described below) to enable the user to select options 
and functions presented on the monitor of /personal computer 405, to 
execute partitioned applications and to process user created events, 
enabling the . partitioned application yo interact with network 10. 
Through^his interaction, the user is yable to input data into fields 
providecH as part of the display, or may individually select choices 
causing;^ standard or personalized/ page to be built Cas explained 
below) @>r display on the monitor of personal computer 405. Such 
inputs ^ill cause RS 400 to interpret events and trigger 
pre-processors or post -processors, retrieve specified objects, 
communicate with system comporpn^^js^ntrol user options, cause the 
display of advertisements on A page, open or close window partitions 
to provide additional navigation possibilities, and collect and report 
data about events, including certain types of objects processed. For 
example, the user may select a particular option, such as opening or 
closing window partition/ 275, which is present on the monitor screen 
414 and follow the selection with a completion key stroke, such as 
ENTER. When the completion keystroke is made, the selection is 
translated into a logical event that triggers the execution of a post- 
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processor (i.e., \a partitioned application program object) to process 
the contents of the field* 

Functions supporting the user-partitioned application interface 
can be performed using the command bar 290, or its equivalent using 
pull down windows on an overlapping cascade of windows. These 
functions can be implemented as part of the RS native functions or can 
be treated as another partition (s) defined for every page for which 
an appropriate set of supporting objects exist and remain resident at 
RS 400. If the functions\are part of RS 400, they can be altered or 
extended by verbs defined \in the RS virtual machine that permit the 
execution of program objects to be triggered when certain f&netions 
are called, providing maximum flexibility. - 4 

To explain the functions the use of a command bar is assumed. 
Command bar 290 is shown in Figures 3(a) and 3(b) and includes a NEXT 
- command 291, a BACK command 292\, a PATH command 293, a MENU command 
294, an^ACTION command 295, a JUMP command 296, a HELP command 297, 
and an EXIT command 298. \ 

NE^T command 291 causes the neVt page in the current page set to 
be buirg!; If the last page of a page set has already been reached, 
NEXT com&and 291 is disabled by RS 40Q, avoiding the presentation of 
an invalid option. \ 

BACK command 292 causes the previous, page of the current page set 
to be btt^lt. If the present page is theVirst in the page set, BACK 
command^92 is disabled, since it is not as, valid option. 

A lilter program can be attached toy both the NEXT or BACK 
functions to modify their implicit sequential nature based upon the 
value of the occurrence in the object set id.\ 

PATH command 293 causes the next page to be built and displayed 
from a list of pages that the user has entered^ starting from the 
first entry for every new session. \ 

MENU command 294 causes the page presenting the previous set of 
choices to be rebuilt. \ 

ACTION command 295 initiates an application dependent operation 
such as causing a new application partition to be interpreted, a 
window partition 275 to be opened and enables the user \o input any 
information required which may result in a transaction ok selection 
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of another window ^c«r page. 

JUMP command 296 causes window partition 275 to be opened, 
allowing the user to\input a keyword or to specify one from an index 
that may be selected for display. 

HELP command 297\, causes a new application partition to be 
interpreted such as a HELP window pertaining to where the cursor is 
positioned to be displayed in order to assist the user regarding the 
present page, a particular partition, or a field in a page element. 

EXIT command 298 causes a LOGOFF page template object (PTO) to 
be built, and a page logoff ^sequence to be presented at RS 400 monitor 
screen 414. \~ 

NAVIGATION INTERFACE 

Continuing, as a further featnire, network 10 includes an improved 
procedure for searching and retrieving applications from the store of 
applicaipLons distributed throughout network 10; e.g., server 205, 
cache/c&hcentrator 302 and RS 400. More specifically, the procedure 
feature^use of pre-created search tables which represent subsets of 
the infqjjrmation on the network arranged with reference to the page 
templat^ objects (PTO) and object-ids oV the available applications 
so that. * in accordance with the procedure^, the relevant tables and 

associated objects can be provided to and searched at the requesting 

\ 

RS 400 without need to search the entire store of applications on the 
network*!? As will be appreciated, this reduces the demand on the 
server 2§5 for locating and retrieving applications for display at 
monitor 412. \ 

In conventional time-sharing networks that support large 
conventional databases, the host receives user requests for data 
records; locates them; and transmits them back \o the users. 
Accordingly, the host is obliged to undertake the data processing 
necessary to isolate and supply the requested infomatAm. And, as 
noted earlier, where large numbers of users are to be served, the many 
user requests can bottleneck at the host, taxing resources and leading 
to response slowdown. \ 

Further, users have experienced difficulty in searching databases 
maintained on conventional time-sharing networks. For example, 
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difficulties have resulted from the complex and varied way previously 
known database suppliers have organized and presented their 
information. Particularly, some database providers require searching 
be done only in selected fields of the database, thus requiring the 
user to be fully familrar with the record structure. Others have 
organized their databases^ on hierarchial structures which require the 
user understand the way the records are grouped. Still further, yet 
other database suppliers Vely upon keyword indices to facilitate 
searching of their records, thus requiring the user to be 
knowledgeable regarding the particular keywords used by the database 
provider. \ 

Network 10, however, is designed to avoid stxph difficulties. In 
the preferred embodiment, the netWork includes procedures for creating 
preliminary searches which represent subsets of the network 
applications users are believed likely to investigate. Particularly, 
in accq^iance with these procedures*, for the active applications 
available on network 10, a library^ of tables is prepared, and 
maintairifd within each of which a plurality of so called "keywords" 
are prodded that are correlated witm page template objects and 
object-ijSs of the entry screen (typically the first screen) for the 
respective application. In the preferred embodiment, approximately 
1,000 tables are used, each having approximately 10 to 20 keywords 
arranged^in alphabetical order to abstractV the applications on the 
network.^; Further, the object-id for each taole is associated with a 
code in &e form of a character string mnemonic which is arranged in 
a set of ^alphabetically sequenced mnemonics termed the sequence set 
so that on entry of a character string at an RS 400, the object-id for 
the relevant keyword table can be obtained from the sequence set. 
Once the table object-id is identified, the keyword table 
corresponding to the desired subset of the objects and associated 
applications can then be obtained from network 10. \subsequently the 
table can be presented to the user's RS 400, whereythe RS 400 can 
provide the data processing required to present the potentially 
relevant keywords, objects and associated applications to the user for 
further review and determination as to whether more ^searching is 
required. As will be appreciated, this procedure reduces demand on 
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server 205 and ^hereby permits it to be less complex and costly , and 
further, reduces\ the likelihood of host overtaxing that may cause 
network response slowdown. 

As a further feature of this procedure, the library of keywords 
and their associated PTOs and objects may be generated by a plurality 
of operations which appear at the user's screen as different search 
techniques. This permits the user to select a search technique he is 
most comfortable with A thus expediting his inquiry. 

More particularly A the user is allowed to invoke the procedure 
by calling up a variety \of operations. The various operations have 
different names and seeircingly present different search strategies. 
Specifically, the user may\invoke the procedure by initiating a "Jump" 
command at RS 400. ThereafDer, in connection with the Jump operation, 
the user, when prompted, majt enter a word of the user's choosing at 
monitor screen 414 relating^ to the matter he is interested in 
locating^ i.e., a subject matter search of the network applications. 
Additionally, the users may iiWoke the procedure by alternatively 
calling an operation termed \lndex" with selection of the Index 
command i^L When selected, the I nde^ command presents the user with an 
alphabetical listing of keywords from the tables noted above which the 
user canK**select from; i.e., an alphabetical search of the network 
applications. Further, the user may evx>ke the procedure by initiating 
an operation termed "Guide." By selecting the Guide command, the user 
is provided with a series of graphic displays that presents a physical 
description of the network applications; Vg., department floor plan 
for a stebre the user may be electronically shopping in. Still 
further, the user may invoke the procedures by. initiating an operation 
termed "Directory." By selecting the Directory command, the user is 
presented with the applications available on the network as a series 
of hierarchial menus which present the content of the network 
information in commonly understood categories. Finally, the user may 
invoke the procedure by selecting the "Path" command, which accesses 
a list of keywords the user has previously selected; i.e., a 
personally tailored form of the Index command descr\bed above. As 
described hereafter, Path further includes a Viewpath operation which 
permits the user to visually access and manage the Path list of 
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keywords. In preferred form, where the user has not selected a list 
of personalized keywords, a default set is provided which includes a 
predetermined list and \associated applications deemed by network 10 
as likely to be of interest to the user. 

This ability to convert these apparently different search 
strategies in a single procedure for accessing pre-created library 
tables is accomplished by translating the procedural elements of the 
different search techniques laito a single set of procedures that will 
produce a mnemonic; i.e., code word, which can first be searched at 
the sequence set, described above to identify the object-id for the 
appropriate library table andV thereafter, enable access of the 
appropriate table to permit selection of the desired keyword and 
associated PTO and object-ids. uShat is to say, the reception system 
native code simply relates the user-entered character string, 
alphabetical range, category, or iist item of respectively, "Jump", 
"Index"^ "Directory", or "Path" \o the table codes through the 
sequence set, so that the appropriate table can be provided to the 
receptions system and application keyword selected. Thus, while the 
search .techniques may appear different to the user, and in fact 
accommodate the user's preferences and sophistication level, they 
nonetheless invoke the same efficient\ procedure of relying upon 
pre-created searches which identify related application PTOs and 
object-i^s so that the table and objects may be collected and 
presentep at the user's RS 400 where they\can be processed, thereby 
relieving^ server 205. \ 

In preferred form, however, in order to enhance presentation 
speed the Guide operation is specially configured. Rather than 
relating the keyword mnemonic to a sequence set. to identify the table 
object-id and range of keywords corresponding Mdo the entry PTO and 
associated object-ids, the Guide operation presents a series of 
overlapping windows that physically describe the "store" in which 
shopping is being conducted or the "building" from\which information 
is being provided. The successive windows increase in degree of 
detail, with the final window presenting a listing of relevant 
keywords. Further, the PTO and object-ids for the application entry 
screen are directly related to the graphic presentation of the 
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keywords. This eliminates the need to provide variable fields in the 
windows for each of the keywords and enables the entry screen to be 
correlated directly with the window graphic. As will be appreciated , 
this reduces the number of objects that would otherwise be Required 
to be staged at RS 400 to support pretention of the keyword listing 
at monitor screen 414, and thus speeds network response. / 

A more detailed understanding of the procedure may/be had upon 
a reading of the following description and review oy accompanying 
FIGS. 2, 3a and particularly FIG. 11 which presents a flow diagram for 
the Jump sequence of the search procedure. / 

To select a particular partitioned application from among 
thousands of such applications residing either at/the RS 400 or within 
delivery system 20, network 10 avoids the need /or a user to know or 
understand, prior to a search, the organization of such partitioned 
applications and the query techniques necessary to access them. This 
is accomplished using a collection of related commands, as described 
below. ^ . . / 

THS Jump command 296 as seen in FIG/ 3a, can be selected, by the 
user fr£>m command bar 290. When Juirfp .command 296 is selected, a 
windowllpartition 275 is opened. In window 275, the user is presented 
and may^select from a variety of displayed options that include among 
others,^ the Directory command, th^e^ndex command, and, the Guide 
comman&V which when selected/ have the effect noted above. 
Additionally, the user can selepx a command termed Viewpath which will 
presents; the keywords that currently make up the list of keywords 
associated with the user's Eath command, and from which list the user 
can select a desired keywoaM. Still further, and with reference Fig. 
11, which shows the sequence where a user offers a term to identify 
a subject of interest/ the user may enter a keyword at display field 
270 within window partition 275 as a "best guess" of the mnemonic 
character strino/that is assigned to a partitioned application the 
user desires (^g., the user may input such english words as "news," 
"pet food, " >games, " etcetera). Where the user enters a character 
string it /is displayed in field 270, and then searched by RS 400 
native code (discussed below) against the sequence sets above noted 
to identify the object-id for the appropriate table of keywords (not 
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shown) that RS 400 may request from host 205. While as noted aboie, 
a table may include 10 to 20 keywords, in the preferred embodiment,' 
for the sake of speed and convenience, a typical keyw 0/ rd table 
includes approximately 12 keywords. 

If the string entered by the user matches a keyword/existing on 
one of the keyword tables, and is thus associated with a/specific PTO, 
RS 400 fetches and displays associated objects ofy^he partitioned 
applications and builds the entry page in accordance with the page 
composition dictated by the target PTO. 

If the string entered by the user does riot match a specific 
keyword, RS 400 presents the user with the option of displaying the 
table of keywords approximating the specific keyword. The approximate 
keywords are presented as initialized, cursorable selector fields of 
the type provided in connection with a Ii4ex command. The user may 
then moge the cursor to the nearest approximation of the mnemonic he 
originaply selected, and trigger navigation to the PTO associated with 
that keyword, navigation being as described hereafter in connection 
with thg! RS 400 native code. 

If-P after selecting the Jump/command, the user selects the Index 
command J RS 400 will retrieve the keyword table residing at RS 400, 
and wilj again build a page with initialized, cursorable fields of 
keyword^. The table fetched/upon invoking the Index command will be 
comprised of alphabetic , keywords that occur within the range of the 
keywordrassociated with the page template object (PTO) from which the 
user iirjpked the Index Command. As discussed above, the user may 
select to navigate to /any of this range of PTOs by selecting the 
relevant keyword fro/ the display. Alternatively, the user can, 
thereafter, select a/other range of alphabetical keywords by entering 
an appropriate character string in a screen field provided or move 
forward or backward in the collection by selecting the corresponding 
option. 

By selecting the Directory command, RS 400 can be caused to fetch 
a table of keywords, grouped by categories, to which the PTO of the 
current partitioned application (as specified by the object set field 
630 off «4 current PEO) belongs. Particularly, by selecting the 
Directory command, RS 400, is causes to displays a series of screens 
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each of which contains alphabetically arranged general subject 
categories from which the user may select. Following selection of a 
category, a series of keywords associated with the specif iedycategory 
are displayed in further screens together with descriptive Statements 
about the application associated with the keywords. Thereafter, the 
user can, in the manner previously discussed with regard/to the Index 
command, select from and navigate to the PTOs of keywords which are 
related to the present page set by subject. / 

The Guide command provides a navigation method related to a 
hierarchical organization of applications provided/on network 10, and 
are described by a series of sequentially presenteia overlaying windows 
of a type known in the art, each of which presents an increasing 
degree of detail for a particular subject area, /terminating in a final 
window that gives keywords associated with thje relevant applications. 
The Guide command makes use of the keyword segment which describes the 
locatioK' of the PTO in a hierarchy (referred to, in the preferred 
embodiment, as the "BFD," or Building-Flopr-Department) as well as an 
associated keyword character string. The BFD describes the set of 
menus tfrat are to be displayed on the screen as the sequence of pop-up 
windows*:. The Guide command may be invoked by requesting it from the 
Jump window described above, or by selecting the Menu command on 
Command-jBar 290. As noted above, /in the case of the Guide command, 
the PTO^nd object-ids for the application entry screen are directly 
associated with the graphic of the keyword presented in the final pop- 
up window. This enables direct /access of the application entry screen 
without need to access the sequence set and keyword table, and thus, 
reduces response time by reducing the number of objects that must be 
processed at RS 400. / 

Activation of the wath command accesses the user's list of 
pre-selected keywords without their display, and permits the user to 
step through the li/st viewing the respective applications by 
repeatedly invokinq/the Path command. As will be appreciated, the 
user cai^ set a priority for selecting keywords and viewing their 
associated applications by virtue of where on the list the user places 
the keywords./ More specifically, if the user has several application 
of particular interest; e.g. , news, weather, etc., the user can place 



them at the top of the list, and quickly step througt^them with the 
Path command. Further, the user can view and randomly access the 
keywords of his list with the Viewpath operation nfoted above. On 
activation of Viewpath, the user's Path keywords areyaisplayed and the 
user can cursor through them in a conventional manner to select a 
desired one. Further, the user can amend the list as desired by 
changing the keywords on the list and/or adjusting their relative 
position. This is readily accomplished by entering the amendments to 
the list presented at the screen 414 with a/ series of amendment 
options presented in a conventional fashion wiyh the list. As noted, 
the list may be personally selected by tip user in the manner 
described, or created as a default by network 10. 

Collectively, the Jump command, Index command, Directory command, 
Guide command, and Path command as described enable the user to 
quickly and easily ascertain the "location'j of either the partitioned 
application presently displayed or the / "location" of a desired 
partitioned application. "Location," as used in reference to the 
prefert^ embodiment means the spec/fic relationships that a 
particular partitioned application bears to other such applications, 
and the jkfethod for selecting particular/partitioned applications from 
such relationships. The techniques/ for querying a database of 
objects ;U embodied in network 10 is an advance over the prior art, 
insofar Sis no foreknowledge of eith4r database structure or query 
technique^ or syntax is necessary, the structure and search techniques 
being ma€e manifest to the user in the course of use of the commands. 

. / 

RS APPLICATION PROTOCOL 

RS protocol defines the wary the RS supports user application 
conversation (input and outpu/) and the way RS 400 processes a 
partitioned application. Part/it ioned applications are constructed 
knowing that this protocol wi/l be supported unless modified by the 
application. The protocol is/ illustrated FIG. 6. The boxes in FIG. 
6 identify processing states that the RS 400 passes through and the 
arrows indicate the transit/ions permitted between the various states 
and are annotated with the/ reason for the transition. 

The various states are: (A) Initialize RS, (B) Process Objects, 
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(C) Interpret ively Execute Pre-processors, (D) Wait for "'Events (E) 
Process Event, and (F) Interpretively Execute Function Extension 
and/or Post-processors. / 

The transitions between states are: (la) Logon Pag4 Template 
Object Identification (PTO-id) , (lb) Object Identification, (2) 
Trigger Program Object identification (PO-id) & retmrn, (3) Page 
Partition Template (PPT) or Window Stack Processing complete, (4) 
Event Occurrence, and (5) Trigger PO-id and Return/ 

Transition (la) from Initialize RS (A) to Process Objects (B) 
occurs when an initialization routine passes tfne object-id of the 
logon PTO to object interpreter 435, when /the service is first 
invoked. Transition (lb) from Process Event/ (F) to Process Objects 
(B) occurs whenever a navigation event causes a new page template 
object identification (PTO-id) to be passedf to object interpreter 435; 
or when a open window event (verb or function key) occurs passing a 
window jilpject-id to the object interpreter 435; or a close window 
event Qtfferb or function key) occurs/ causing the current top-most 
window be closed. / 

Whi^fe in the process object state, object interpreter 435 will 
request ^hy objects that are identified by external references in call 
segments V Objects are processed by parsing and interpreting the 
object asfed its segments according to the specific object architecture. 
As objeqff interpreter 435 processes objects, it builds a linked list 
structure;!! called a page processing table (PPT), shown in FIG. 10, to 
reflect ilfte structure of the page, each page partition, Page Element 
Objects ifPEOs) required J program objects (POs) required and each 
window object (WO) that could be called. Object interpreter 435 
requests all objects ^required to build a page except objects that 
could be called as the result of some event, such as a HELP window 
ob j ect . / 

Transition (2) from Process Objects (B) to Interpretively Execute 
Pre-processors yC) occurs when the object interpreter 435 determines 
that a pre-processor is to be triggered. Object processor 436 then 
passes the object-id of the program object to the TBOL interpreter 
438. TBOL interpreter 438 uses the RS virtual machine to 
interpretively execute the program object. The PO can represent 
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either a selector or an initializer. When execution is complete, a 
transition automatically occurs back to Process Objects (B) . / 

Selectors are used to dynamically link and load otherYobjects 
such as PEOs or other PDOs based upon parameters that they sure passed 
when they are called. Such parameters are specified in cafll segments 
or selector segments. This feature enables RS 400 to /conditionally 
deliver information to the user base upon predetermined parameters, 
such as his personal demographics or locale. For example, the 
parameters specified may be the transaction codes required to retrieve 
the user's age, sex, and personal interest efodes from records 
contained in user profiles stored at the switch/ file server layer 200. 

Initializers are used to set up the application processing 
environment for a partitioned application and determine what events 
RS 400 may respond to and what the action wall be. 

Transition (3) from Process Objects /(B) to Wait for Event (D) 
occurs Men object interpreter 435 is finished processing objects 
associated with the page currently bein^ built or opening or closing 
a windoW^ on a page. In the Wait fpr Event state (D) , an input 
manager, J^which in the preferred form yShown includes keyboard manager 
4 34 seen^in Fig. 8, accepts user inputs. All keystrokes are mapped 
from their physical codes to logical keystrokes by the Keyboard 
Manager l 43 4, representing keystrokes recognized by the RS virtual 
machine.;^ / 

Whey the cursor is located in a field of a page element, 
keystrokes are mapped to theT field and the partitioned external 
variable ^(PEV) specified inr the page element object (PEO) field 
definition segment by the cooperative action of keyboard manager, 434 
and display manager 461. / Certain inputs, such as RETURN or mouse 
clicks in particular fields, are mapped to logical events by keyboard 
manager 434, which are called completion (or commit) events. 
Completion events signify the completion of some selection or 
specification process associated with the partitioned application and 
trigger a partition level and/or page level post-processor to process 
the faction" parameters associated with the user's selection and 
commit event. / 

Such parameters are associated with each possible choice or 
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input, and are set up by the earlier interpretive execution of an 
initializer pre-processor in state (C) . Parameters usually specify 
actions to perform a calculation such as the balanc^aue on an order 
of several items with various prices using sales/tax for the user's 
location, navigate to PTO-iS, open window Wp^-id or close window. 
Actions parameters that involve the specification of a page or window 
object will result in transition (lb) to tHe Process Objects (B) state 
after the post -processor is invoked as/explained below. 

Function keys are used to specify one or more functions which are 
called when the user strikes thejye keys. Function keys can include 
the occurrence of logical events, as explained above. Additionally, 
certain, functions may be "filtered" , that is, extended or altered by 
SET_FUNCTION or TRIGGER FJJNCTION verbs recognized by the RS virtual 
machine. Function keys/cause the PO specified as a parameter of the 
verb to be interpret i^ely executed whenever that function is called. 
Applications use this technique to modify or extend the functions 

bafts' / 

providecHby the RS . 

Tr^j£itiorr (5) from Process Event (E) to Interpret ively Execute 
Pre-proqessors (F) occurs when Process Event State determines that a 
post-proeessor or function extension PDO is to be triggered. The id 
of the pijpgram object is then passed to the TBQL interpreter 438. The 
TBOL interpreter 438 uses the RS virtual machine to interpret ively 
exeotite tpie PO. When execution is complete a transition automatically 
o$x^urs bfpk to Process Event (E) . 

RECEPTION SYSTEM SOFTWARE 

The reception system 400 software is the interface between the 
user of personal computer 405 and interactive network 10. The object 
of reception system software is to minimize mainframe processing, 
minimize transmission across the network, and support application 
extendibility and portability. 

RS 4 00 software is composed of several layers, as shown in FIG. 
7. It includes external ; software 451, which is composed of elements 
well known to the art such as device drivers, the native operating 
systems; e.g., MS-DOS, machine-specific assembler functions (in the 
preferred embodiment; e.g., CRC error checking), and "C" runtime 
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library functions; native software 420; and partitioned applications 
410. 

Again with reference to FIG, 7, native software 420 is compiled 
from the "C" language into a target machine-specific executable, and 
is composed of two components: the service software 430 and the 
operating environment 450. Operating environment 450 is comprised of 
the Logical Operating System 432, or LOS; and a multitasker 433. 
Service software 430 provides functions specific to providing 
interaction between the user and interactive network 10, while the 
operating environment 450 provides pseudo multitasking and access to 
local physical resources in support of service software 430. Both 
layers of native software 420 contain kernel, or device independent 
functions 430 and 432, and machine-specific or device dependent 
functions 433. All device dependencies are in code resident at RS 
400, and are limited to implementing only those functions that are not 
common across machine types, to enable interactive network 10 to 
provide ;S single data stream to all makes of personal computer which 
are of tSie IBM or IBM compatible type. Source code for the native 
software*;^ 0 is included in parent application serial number 388,156 
now issued as U.S. patent , the contents of which patent are 
incorporated herein by reference . Those interested in a more detailed 
description of the reception system software may refer to the source 
code provided in the referenced patent. 

Service software 430 is comprised of modules, which are 
device- irfileperident software components that together obtain, interpret 
and store partitioned applications existing as a collection of 
objects. The functions performed by, and the relationship between, 
the service software 430 module is shown in FIG. 8 and discussed 
further below. 

Through facilities provided by LOS 432 and multitasker 433, here 
called collectively operating environment 450, device- independent 
multitasking and access to local machine resources, such as 
multitasking, timers, buffer management, dynamic memory management, 
file storage and access, keyboard and mouse input, and printer output 
are provided. The operating environment 450 manages communication and 
synchronization of service software 43 0, by supporting a 
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request/response protocol and managing the interface between the 
native software 420 and external software 437. 

Applications software layer 410 consists of programs and data 
written in an interpretive language, "TRINTEX Basic Object Language" 
or "TBOL, " described above. TBOL was written specifically for use in 
RS 400 and interactive network 10 to facilitate videotext-specif ic 
commands and achieve machine-independent compiling. TBOL is 
constructed as objects, which in interaction with one another comprise 
partitioned applications. 

RS native software 420 provides a virtual machine interface for 
partitioned applications, such that all objects comprising partitioned 
applications "see" the same machine. RS native software provides 
support for the following functions: (l) keyboard and mouse input; (2) 
text and graphics display; (3) application interpretation; (4) 
application database management; (5) local application storage; (6) 
network Mand link level communications; (7) user activity data 
collection; and (8) advertisement management. 

Witk reference to FIG. 8, service software 430 is comprised of 
the following modules: start-up (not shown); keyboard manger 434; 
object interpreter 435; TBOL interpreter 438; object storage facility 
439; display manager 461; data collection manager 441; ad manager 442; 
object/cgmmunications manager interface 443; link communications 
manager ^44; and fatal error manager 469.. Each of these modules has 
responsibility for managing a different aspect of RS 4.00. 

Sta i© :up reads R S 400 customization options into RAM, including 
modem, device driver and telephone number options, from the file 
CONFIG. SM. Startup invokes all RS 400 component startup functions, 
including navigation to the first page, a logon screen display 
containing fields initialized to accept the user's id and password. 
Since Startup is invoked only at initialization, for simplicity, it 
has not been shown in FIG. 8. 

The principal function of keyboard manger 434 is to translate 
personal computer dependent physical input into a consistent set of 
logical keys and to invoke processors associated with these keys. 
Depending on the LOS key, and the associated function attached to it, 
navigation, opening of windows, and initiation of filter or 
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post-processor TBOL programs may occur as the result input events 
handled by the keyboard manger 434. In addition, keyboard manger 434 
determines inter and intra field cursor movement, and coordinates the 
display of field text and cursor entered by the user with display 
manager 461, and sends information regarding such inputs to data 
collection manager 441. 

Object interpreter 435 is responsible for building and 
recursively processing a table called the "Page Processing Table," or 
PPT. Object interpreter 435 also manages the opening and closing of 
windows at the current page. Object interpreter 435 is implemented 
as two sub-components: the object processor 436 and object scanner 
437. 

Object processor 43 6 provides an interface to keyboard manger 434 
for navigation to new pages, and for opening and closing windows in 
the current page. Object processor 436 makes a request to object 
storage JPacility 439 for a page template object (PTO) or window object 
(WO), as* requested by keyboard manger' 434, and for objects and their 
segmentsSLwhich comprise the PTO or WO returned by object storage 
facility2 : 439 to object processor 436. Based on the particular 
segments ^comprising the object (s) making up the new PTO or WO, object 
processor 436 builds or adds to the page processing table (PPT) , which 
is an iri€ernal, linked-list, global data structure reflecting the 
structure of the page or page format object (PFO) , each page partition 

or page ^iement object (PEO) , and program objects (POs) required and 

&\ 

each window object (WO) that could be called. Objects are processed 
by parsing and interpreting each object and its segment (s) according 
to their particular structure as formalized in the data object 
architecture (DOA) . While in the process object state, (state "B" of 
Fig. 6) , object processor 43 6 will request any objects specified by 
the PTO that are identified by external references in call segments 
(e.g. field level program call 518, page element selector call 524, 
page format call 526 program call 532, page element call 522 segments) 
of such objects, and will, through a request to TBOL interpreter 438, 
fire initializers and selectors contained in program data segments of 
all PTO constituent program objects, at the page, element, and field 
levels. Object processor 436 requests all objects required to build 
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a page, except objects that could only be called as the result of some 
event external to the current partitioned application, such as a HELP 
window object. When in the course of building or adding to the PPT 
and opening/closing WOs, object processor encounters a call to an 
"ADSLOT" object id, the next advertisement object id at ad manager 442 
is fetched, and the identified advertisement object is retrieved 
either locally, if available, or otherwise from the network, so that 
the presentation data for the advertisement can be sent to display 
manager 461 along with the rest of the presentation data for the other 
objects to enable display to the user. Object processor 436 also 
passes to data collection manager 441 all object ids that were 
requested and object ids that were viewed. Upon completion of page 
or window processing, object processor 436 enters the wait for event 
state, and control is returned to keyboard manger 434. 

Thejsecond component of object interpreter 435, object scanner 
437, presides a file-like interface, shared with object storage 
facility>439, to objects currently in use at RS 400, to enable object 
processo^L 43 6 to maintain and update the PPT. Through facilities 
provided,^; by object scanner 437, object processor recursively 
constructs a page or window in the requested or current partitioned 
application, respectively. 

In accordance with the invention, object storage facility 439 
provides ^n interface through which object interpreter 435 and TBOL 
interpreter 438 either synchronously request (using the TBOL verb 
operator fi*GET" ) objects without which processing in either module 
cannot continue, or asynchronously request (using the TBOL verb 
operator "FETCH") objects in anticipation of later use. Object 
storage facility 439 returns the requested objects to the requesting 
module once retrieved from either local store 440 or interactive 
network 10. Through control structures shared with the object scanner 
437, object storage facility determines whether the requested object 
resides locally, and if not, makes an attempt to obtain it from 
interactive network 10 through interaction with link communications 
manager 444 via object/communications manager interface 443. 

When objects are requested from object storage facility 439, only 
the latest version of the object will be provided to guarantee 
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currency of information to the user. Object storage facility 439 
assures currency by requesting version verification from network 10 
for those objects which are available locally and by requesting 
objects which are not locally available from delivery system 20 where 
currency is maintained. 

Version verification increases response time. Therefore, not all 
objects locally available are version checked each time they are 
requested. Typically, objects are checked only the first time they 
are requested during a user session. However, there are occasions, 
as for example in the case; of objects relating to news applications, 
where currency is always checked to assure integrity of the 
information. 

The frequency with which the currency of objects is checked 
depends on factors such as the frequency of updating of the objects. 
For example, objects that are designated as ultrastable in a storage 
control parameter in the header of the object are never version 
checked Unless a special version control object sent to the RS as part 
of logon ^indicates that all such objects must be version checked. 
Object sforage facility 4 39 marks all object entries with such a 
stability^ category in all directories indicating that they must be 
version checked the next time they are requested. 

Objept storage facility 439 manages objects locally in local 
store 4405*' comprised of a cache (segmented between available RAM and 
a fixed sf-ze disk file) , and stage (fixed size disk file) . Ram and 
disk cached objects are retained only during user sessions, while 
objects stbred in the stage file are retained between sessions. The 
storage control field, located in the header portion of an object, 
described more fully hereafter as the object "storage candidacy", 
indicates whether the object is stageable, cacheable or trashable. 

Stageable objects must not be subject to frequent change or 
update. They are retained between user sessions on the system, 
provided storage space is available and the object has not discarded 
by a least-recently-used (LRU) algorithm of a conventional type; e.g., 
see Operating System Theory , by Coffman, Jr. and Denning, Prentice 
Hall Publishers, New York, 1973, which in accordance with the 
invention, operates in combination with the storage candidacy value 
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to determine the object storage priority, thus rendering the stage 
self -configuring as described more fully hereafter . Over time, the 
self-configuring stage will have the effect of retaining within local 
disk storage those objects which the user has accessed most often. 
The objects retained locally are thus optimized to each individual 
user's usage of the applications in the system. Response time to such 
objects is optimized since they need not be retrieved from the 
interactive computer system. 

Cacheable objects can be retained during the current user 
session, but cannot be retained between sessions. These objects 
usually have a moderate update frequency. Object storage facility 439 
retains objects in the cache according to the LRU storage retention 
algorithm. Object storage facility 439 uses the LRU algorithm to 
ensure that objects that are least frequently used forfeit their 
storage to objects that are more frequently used. 

Tradable objects can be retained only while the user is in the 
context the partitioned application in which the object was 

requested. Trashable objects usually have a very high update 
frequencjpTand must not be retained to ensure that the user has access 
to the mey&t current data. , 

More^ particularly and, as noted above, in order to render a 
public informational and transactional network of the type considered 
here attractive, the network must be both economical to use and fast. 
That is t^say, the network must supply information and transactional 
support tgEthe user at minimal costs and with a minimal response time. 
In accordance with the present invention, these objectives are sought 
to be achieved by locating as many information and transactional 
support objects which the user is likely to request, as close to the 
user as possible; i.e., primarily at the user's RS 400 and secondarily 
at delivery system 20. In this way, the user will be able to access 
objects required to support a desired application with minimal 
intervention of delivery system 20, thus reducing the cost of the 
session and speeding the response time. 

However, the number of objects that can be maintained at RS 400 
is restricted by at least two factors: the RS 400 storage capacity; 
i.e., RAM and disk sizes, and the need to maintain the stored objects 
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current . 

In order to optimize the effectiveness of the limited storage 
space at RS 400, the collection of objects is restricted to those 
likely to be requested by the user; i.e., tailored to the user's 
tastes - and to those least likely to be time sensitive; i.e., objects 
which are stable. To accomplish this, objects are coded for storage 
candidacy to identify when they will be permitted at RS 400, and 
subject to the LRU algorithm to maintain presence at RS 400. 
Additionally, to assjure currency of the information and transaction 
support provided at RS 400, objects are further coded for version 
identification and checking in accordance with a system of priorities 
that are reflected in the storage candidacy coding. 

Specifically, to effect object storage management, objects are 
provided with a coded version id made up of the storage control byte 
and version control bytes identified above as elements of the object 
header, sgjecif ically , bytes 16 and 18 shown in FIG. 4b. In preferred 
form, the^version id is comprised of bytes 16 and 18 to define two 
fields, ag^; first 13 bit field to identify the object version and a 
second thgee bite field to identify the object storage candidacy. 

In tfeis arrangement, the storage candidacy value of the object 
is addressed to not only the question of storage preference but also 
object currency. Specifically, the storage candidacy value 
establishes the basis upon which the object will be maintained at RS 
400 and alpo identifies the susceptibility of the object to becoming 
stale by dictating when the object will be version checked to 
determine "currency . 

The version value of the object on the other hand, provides a 
parameter that can be checked against predetermined values available 
from delivery system 20 to determine whether an object stored at RS 
400 is sufficiently current to permit its continued use, or whether 
the object has become stale and needs to be replaced with a current 
object from delivery system 20. 

Still further, object storage management procedure further 
includes use of the LRU algorithm, for combination with the storage 
and version coding to enable discarding of objects which are not 
sufficiently used to warrant retention, thus personalizing the store 
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of objects at RS 400 to the user's tastes* Particularly, object 
storage facility 439, in accordance with the LRU algorithm maintains 
a usage list for objects. As objects are called to support the user's 
applications requests, the objects are moved to the top of a usage 
list. As other objects are called, they push previously called 
objects down in the list. If an object is pushed to the bottom of the 
list before being recalled, it will be forfeited from the list if 
necessary to make room for the next called object. As will be 
appreciated, should a previously called object be again called before 
it is displaced from the list, it will be promoted to the top of the 
list, and once more be subject to depression in the list and possible 
forfeiture as other objects are called. 

As pointed out above, in the course of building the screens 
presented to the user, objects will reside at various locations in RS 
400. For example, objects may reside in the RS 400 RAM where the 
object i ^supporting a particular application screen then running or 
in a cache maintained at either RAM or disk 424 where the object is 
being helj€l for an executing application or staged on the fixed size 
file on dlfesk 424 noted above where the object is being held for use 
in application likely to be called by the user in the future. 

In operation, the LRU algorithm is applied to all these regions 
and serve^ to move an object from RAM cache to disk cache to disk 
file, and^otentially off RS 400 depending on object usage. 

With Regard to the storage candidacy value, in this arrangement, 
the objecfib stored at RS 400 include a limited set of permanent 
objects; '%*q., those supporting logon and logoff, and other 
non-permanent objects which are subject to the LRU algorithm to 
determine whether the objects should be forfeited from RS 400 as other 
objects are added. Thus, in time, and. based on the operation of the 
LRU algorithm and the storage candidacy value, the collection of 
objects at RS 400 will be tailored to the usage characteristics of the 
subscriber; i.e. , self -configuring. 

More particularly, the 3 -bit field of the version id that 
contains the storage candidacy parameter can have 8 different values. 
A first candidacy value is applied where the object is very sensitive 
to time; e.g., news items, volatile pricing information such as might 
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apply to stock quotes, etc. In accordance with this first value, the 
object will not be permitted to be stored on RS 400, and RS 400 will 
have to request such objects from delivery system 20 each time it is 
accessed, thus, assuring currency. A second value is applied where 
the object is sensitive to time but less so than the first case; e.g., 
the price of apples in a grocery shopping application. Here, while 
the price might change from day to day, it is unlikely to change 
during a session. Accordingly the object will be permitted to 
persist in RAM or at the disk cache during a session, but will not be 
permitted to be maintained at RS 400 between sessions. 

Continuing down the hierarchy of time sensitivity, where the 
object concerns information sufficiently stable to be maintained 
between sessions, a third storage candidacy value is set to permit the 
object to be stored at RS 400 between sessions, on condition that the 
object will be version check the first time it is accessed in a 
subsequeiJE session. As will be appreciated, during a session, and 
under the^ffect of the LRU algorithm, lack of use at RS 400 of the 
object ma*£ result in it being forfeited entirely to accommodate new 
objects called for execution at RS 400. 

Stilly further, a fourth value of storage candidacy is applied 
where the,g object is considered sufficiently stable as not to require 
version Recking between sessions; e.g., objects concerning page 
layouts mot anticipated to change. In this case, the storage 
candidacy Rvalue may be encoded to permit the object to be retained 
from session to session without version checking. Here again, 
however, the LRU algorithm may cause the object to forfeit its storage 
for lack of use. 

Where the object is of a type required to be stored at RS 400, 
as for example, objects needed to support standard screens, it is 
coded for storage between sessions and not subject to the LRU 
algorithm forfeiture. However, where such objects are likely to 
change in the future they may be required to be version checked the 
first time they are accessed in a session and thus be given a fifth 
storage candidacy value. If, on the other hand, the required stored 
object is considered likely to be stable and not require even version 
checking; e.g., logon screens, it will be coded with a sixth storage 
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candidacy value for storage without version checking so as to create 
a substantially permanent object. 

Continuing, where a RS 400 includes a large amount of combined 
RAM and disk capacity, it would permit more objects to be stored. 
However, if objects were simply coded in anticipation of the larger 
capacity, the objects would potentially experience difficulty, as for 
example, undesired forfeiture due to capacity limitations if such 
objects were supplied to RS 400 units having smaller RAM and disk 
sizes. Accordingly, to take advantage of the increased capacity of 
certain RS 400 units without creating difficulty in lower capacity 
units, objects suitable for storage in large capacity units can be so 
coded for retention between sessions with a seventh and eighth storage 
candidacy value depending upon whether the stored large capacity 
object recjuires version checking or not. Here, however, the coding 
will be ijafcerpreteid by smaller capacity units to permit only cacheable 
storage t& avoid undesirable forfeiture that might result from over 
filling f$fp smaller capacity units. 

Wherg an object is coded for no version checking need may 
nonetheless arise for a version check at some point. To permit 
version checking of such objects, a control object is provided at RS 
400 that mky be version checked on receipt of a special communication 
from delivery system 20. If the control object fails version check, 
then a orjp shot version checking attribute is associated with all 
existing Objects in RS 400 that have no version checking attributes. 
Thereafter^ the respective objects are version checked, the one shot 
check attribute is removed and the object is caused to either revert 
to its previous state if considered current or be replaced if stale. 

Still further, objects required to be stored at RS 400 which are 
not version checked either because of lack of requirement or because 
of no version check without a control object, as described above, can 
accumulate in RS 400 as dead objects. To eliminate such accumulation, 
all object having required storage are version checked over time. 
Particularly, the least recently used required object is version 
checked during a session thus promoting the object to the top of the 
usage list if it is still to be retained at RS 400. Accordingly, one 
such object will be checked per session and over time, all required 
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objects will be version checked thereby eliminating the accumulation 
of dead objects. 

However, in order to work efficiently, the version check 
attribute of the object should be ignored, so that even required 
object can be version checked. Yet, in certain circumstances, e.g., 
during deployment of new versions of the reception system software 
containing new objects not yet supported on delivery system 20 which 
may be transferred to the fixed storage file of RS 400 when the new 
version is loaded, unconditional version checking may prematurely 
deletes the object from the RS 400 as not found on delivery system 20. 
To avoid this problem, a sweeper control segment in the control object 
noted above can be used to act as a switch to turn the sweep of dead 
objects on and off. 

With respect to version checking for currency, where an object 
stored at RS 400 is initially fetched or accessed during a session, 
a reque^'|lp delivery system 20 is made for the object by specifying 
the ver$Acm id of the object stored at RS 400. 

In' j^ponse, delivery system 20 will advise the reception system 
400 eit^s^; that the version id of the stored object matches the 
currency v&lue ; i.e., the stored object is acceptable, or deliver a 
current pbject that will replace the stored object shown to be stale. 
Alternatively , the response may be that the object was not found. If 
the ver$Jo^of the stored object is current, the stored object will 
be used japtjl verified again in accordance with its storage candidacy. 
-If the s€br%!d object is stale, the new object delivered will replace 
the old (31ie*and support the desired screen. If the response is object 
not found, the stored object will be deleted. 

Therefore, based on the above description, network 10 is seen to 
include steps for execution at storage facility 439 which enables 
object reception, update and deletion by means of a combination of 
operation of the LRU algorithm and interpretation of the storage 
candidacy and version control values. In turn, these procedures 
cooperate to assure a competent supply of objects at RS 400 so as to 
reduce the need for intervention of delivery system 20, thus reducing 
cost of information supply and transactional support so as to speed 
the response to user requests. 
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TBOL interpreter 438 shown in Fig. 8 provides the means for 
executing program objects, which have been written using an 
interpretive language, TBOL described above ♦ TBOL interpreter 438 
interprets operators and operand contained in program object 508, 
5 manages TBOL variables and data, maintains buffer and stack 
facilities, and provides a runtime library of TBOL verbs. 

TBOL verbs provide support for data processing, program flow 
control, file management, object management, communications, text 
display, command bar control, open/close window, page navigation and 
0 sound. TBOL interpreter also interacts with other native modules 
) through commands contained in TBOL verbs. For example: the verb 
"navigate" will cause TBOL interpreter 438 to reguest object 
interpreter 435 to build a PPT based on the PTO id contained in the 
operand of the NAVIGATE verb; "fetch" or "GET" will cause TBOL 
5 interpreter 438 to request an object from object storage facility 439; 
"SETjgJNC^tON" will assign a filter to events occurring at the 
keyboard ganger 434; and "FORMAT," "SEND," and "RECEIVE" will cause 
TBOL ^interpreter 4 38 to send application level requests to 
objeqt^comapunications manager interface 433. 
0 Bkta;&reas managed by TBOL interpreter 438 and available to TBOL 

programs ^Ire Global External Variables (GEVs) , Partition External 
VariafeO.es ;4PEVs) , and Runtime Data Arrays (RDAs) . 

jdEVs ^bntain global and system data, and are accessible to all 
progrfin objects as they are executed. GEVs provide a means by which 
!5 program objects may communicate with other program objects or with the 
RS native cfode, if declared in the program object. GEVs are character 
string variables that take the size of the variables they contain. 
GEVs may preferably contain a maximum of 32,000 variables and are 
typically used to store such information as program return code, 
30 system date and time, or user sex or age. TBOL interpreter 438 stores 
such information in GEVs when requested by the program which initiated 
a transaction to obtain these records from the RS or user's profile 
stored in the interactive system. 

Partition external variables (PEVs) have a scope restricted to 
35 the page partition on which they are defined. PEVs are used to hold 
screen field data such that when PEOs and window objects are defined, 
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the fields in the page partitions with which these objects are to be 
associated are each assigned to a PEV. When applications are 
executed , TBOL interpreter 438 transfers data between screen fields 
and their associated PEV. When the contents of a PEV are modified by 
user action or by program direction, TBOL interpreter 428 makes a 
request to display manager 461 to update the screen field to reflect 
the change. PEVs are also used to hold partition specific application 
data, such as tables of information needed by a program to process an 
expected screen input. 

Because the scope of PEVs is restricted to program ob j ects 
associated with the page partition in which they are defined, data 
that is to be shared between page partitions or is to be available to 
a page-level processor must be placed in GEVs or RDAs. 

RDAs are internal stack and save buffers used as general program 
work areas. RDAs are dynamically defined at program object "runtime" 
and are tfped for communication and transfer of data between programs 
when the^rdata to be passed is not amenable to the other techniques 
available^ Both GEVs and RDAs include, in the preferred embodiment, 
8 integer] registers and 8 decimal registers. Preferably, there are 
also 9 parameter registers limited in scope to the current procedure 
of a program object. 

All variables may be specified as operand of verbs used by the 
virtual %ichine. The integer and decimal registers may be specified 
as operaiid for traditional data processing. The parameter registers 
are used *f or passing parameters to "called" procedures. The contents 
of these registers are saved on an internal program stack when a 
procedure is called, and are restored when control returns to the 
"calling" procedure from the "called" procedure. 

TBOL interpreter 438, keyboard manger 434, object interpreter 
435, and object storage facility 439, together with device control 
provided by operating environment 450, have principal responsibility 
for the management and execution of partitioned applications at the 
RS 400. The remaining native code modules function in support and 
ancillary roles to provide RS 400 with the ability display partitioned 
applications to the user (display manager 461) , display advertisements 
(ad manager 442), to collect usage data for distribution to 




interactive network 10 for purposes of targeting such advertisements 
(data collection manager 441), and prepare for sending, and send, 
objects and messages to interactive network 10 (object/communications 
manager interface 443 and link communications manager 444) Finally, 
the fatal error manager exists for one purpose: to inform the user of 
RS 400 and transmit to interactive network 10 the inability of RS 400 
to recover from a system error. 

Display manager 461 interfaces with a decoder using the North 
American Presentation Level Protocol Syntax (NAPLPS) , a standard for 
encoding graphics data, or text code, such as ASCII, which are 
displayed on monitor 412 of the user's personal computer 405 as 
pictorial codes. Codes for other presentation media, such as audio, 
can be specified by using the appropriate type code in the 
presentation data segments. Display manager 461 supports the 
following functions: send NAPLPS strings to the decoder; echo text 
from a PE¥; move the cursor within and between fields; destructive or 
non-dest^ctive input field character deletion; "ghost" and "unghost" 
fields ^IQsl ghosted field is considered unavailable, unghosted 
availably ; turn off or on the current field cursor; open, close, save 
and restore bit maps for a graphics window; update all current screen 

fields by displaying the contents of their PEVs, reset the NAPLPS 
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decoder jt;o a known state; and erase an area of the screen by 
generatiilg and sending NAPLPS to draw a rectangle over that area. 
Display ^ftjanager 461 also provides a function to generate a beep 
through &p interface with a machine-dependent sound driver. 

Ad manager 442 is invoked by object interpreter 435 to return the 
object id of the next available advertisement to be displayed. Ad 
manager 442 maintains a queue of advertising object id's targeted to 
the specific user currently accessing interactive network 10. 
Advertising objects are pre-f etched from interactive system 10 from 
a personalized queue of advertising ids that is constructed using data 
previously collected from user generated events and/or reports of 
objects used in the building of pages or windows, compiled by data 
collection manager 466 and transmitted to interactive system 10. 

Advertising objects 510 are PEOs that, through user invocation 
of a "LOOK" command, cause navigation to partitioned applications that 
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may themselves support, for example, ordering and purchasing of 
merchandise. 

An advertising object id list, or "ad queue," is requested in a 
transaction message to delivery system 20 by ad manager 442 
5 immediately after the initial logon response. The logon application 
at RS 400 places the advertising list in a specific RS global storage 
area called a SYS_GEV (system global external variable) , which is 
accessible to all applications as well as to the native RS code) . The 
Logon application also obtains the first two ad object id f s from the 

L0 queue and provides , them to object storage facility 439 so the 
advertising objects can be requested. However, at logon, since no 
advertising objects are available at RS local storage facilities 440, 
ad objects, in accordance with the described storage candidacy, not 
being retained at the reception system between sessions, they must be 

.5 requested from interactive network 10. 

accordance wi th the pre f erred form o f network 1 0 , the 
following parametric values are established for ad manager 442: 
advertising object is queue capacity, replenishment threshold for 
advertising object id's and replenishment threshold for number of 

0 outstanding pre-f etched advertising objects. These parameters are set 
up in^EVs of the RS virtual machine by the logon application program 
object from the logon response from high function system 110. The 
parameters are then also accessible to the ad manager 442. Preferred 
valuepare an advertising queue capacity of 15, replenishment value 

5 of 10^ empty queue positions and a pre-f etched advertising object 
threshold of 3. 

Ad manager 442 pre-f etches advertising objects by passing 
advertising object id's from the advertising queue to object storage 
facility 439 which then retrieves the object from the interactive 

0 system if the object is not available locally. Advertising objects 
are pre-fetched, so they are available in RS local store 440 when 
requested by object interpreter 435 as it builds a page. The ad 
manager 442 pre-f etches additional advertising objects whenever the 
number of pre-fetched advertising objects not called by object 

5 interpreter 435; i.e. the number of remaining advertising objects, 
falls below the pre-fetch advertising threshold. 
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Whenever the advertising object id queue has more empty positions 
than replenishment threshold value, a call is made to the advertising 
object id queue application in high function system 110 shown in FIG. 
2, via object/communications manager interface 443 for a number of 
5 advertising object id's equal to the threshold value. The response 
message from system 110 includes a list of advertising object id f s, 
which ad manager 442 enqueues. 

Object interpreter 435 requests the object id of the next 
advertising object from ad manager 442 when object interpreter 435 is 

L0 building a page and encounters an object call for a partition and the 
specified object-id equals the code word, "ADSLOT." If this is the 
first request for an advertising object id that ad manager 442 has 
received during this user's session, ad manager 442 moves the 
advertising object id list from the GEV into its own storage area, 

L5 whicl^it uses as an advertising queue and sets up its queue management 
pointers, knowing that the first two advertising objects have been 
pre- ^tched. 

%d manager 442 then queries object storage facility 439, 
irrespective of whether it was the first request of the session. The 

20 query^jasks if the specified advertising object id pre-fetch has been 
completed, i.e., is the object available locally at the RS. If the 
obje^J is available locally, the object-id is passed to object 
interpreter 435, which requests it from object storage facility 439. 
If tK§ advertising object is not available in local store 440, ad 

25 managjjr 442 attempts to recover by asking about the next ad that was 
pre-f etched. This is accomplished by swapping the top and second 
entry in the advertising queue and making a query to object storage 
facility 439 about the new top advertising object id. If that object 
is not yet available, the top position is swapped with the third 

30 position and a query is made about the new top position. 

Besides its ability to provide advertising that have been 
targeted to each individual user, two very important response time 
problems have been solved by ad manager 442 of the present invention. 
The first is to eliminate from the new page response time the time it 

35 takes to retrieve an advertising object from the host system. This 
is accomplished by using the aforementioned pre-fetching mechanism. 
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The second problem is caused by pre-f etching, which results in 
asynchronous concurrent activities involving the retrieval of objects 
from interactive system 10. If an advertising object is pre-fetched 
at the same time as other objects required for a page are requested, 
the transmission of the advertising object packets could delay the 
transmission of the other objects required to complete the current 
page by the amount of time required to transmit the advertising 
object (s). This problem is solved by the structuring the requests 
from object interpreter 435 to the ad manager 442 in the following 
way: 

1. Return next object id of pre-fetched advertising object & 
pre-f etch another; 

2. Return next advertising object id only; and 

3. Pre-fetch next advertising object only. 

|y separating the function request (1) into its two components, 
(2) ai|| (3), object interpreter 435 is now able to determine when to 
request advertising object id's and from its knowledge of the page 
build,|process, is able to best determine when another advertising 
objectB can be pre-fetched, thus causing the least impact on the page 
respo|in|e time. For example, by examining the PPT, object interpreter 
435 may determine whether any object requests are outstanding. If 
there jre outstanding requests, advertising request type 2 would be 
used. ^ When all requested objects are retrieved, object interpreter 
435 tgfen issues an advertising request type 3. Alternatively, if 
there %re no outstanding requests, object interpreter 435 issues an 
advertising request type 1. This typically corresponds to the user's 
"think time" while examining the information presented and when RS 400 
is in the Wait for Event state (D) . 

Data collection manager 441 is invoked by object interpreter 435 
and keyboard manger 434 to keep records about what objects a user has 
obtained (and, if a presentation data segment 530 is present, seen) 
and what actions users have taken (e.g. "NEXT," "BACK," "LOOK," etc.) 

The data collection events that are to be reported during the 
user's session are sensitized during the logon process. The logon 
response message carries a data collection indicator with bit flags 
set to "on" for the events to be reported. These bit flags are 
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enabled (on) or disabled (off) for each user based on information 
contained in the user's profile stored and sent from high function 
host 110. A user's data collection indicator is valid for the 
duration of his session. The type of events to be reported can be 
5 changed at will in the host data collection application. However, 
such changes will affect only users who logon after the change. 

Data collection manager 441 gathers information concerning a 
user's individual system usage characteristics. The types of 
informational services accessed , transactions processed, time 

10 information between various events, and the like are collected by data 
collection manager 441, which compiles the information into message 
packets (not shown) . The message packets are sent to network 10 via 
object/communication manager interface 443 and link communications 
manager 444. Message packets are then stored by high function host 

L5 110 and sent to an offline processing facility for processing. The 
characteristics of users are ultimately used as a means to select or 
targefe various display objects, such as advertising objects, to be 
sent '$p particular users based on consumer marketing strategies, or 
the Igjce, and for system optimization. 
0 ^Sbject/communications manager interface 443 is responsible for 

sendiffg and receiving DIA (Data Interchange Architecture described 
above;)** formatted messages to or from interactive network 10. 
Ob jec^/ communications manager 443 also handles the receipt of objects, 
buildjSfL; a DIA header for messages being sent and removes the header 

jr. 

5 from deceived DIA messages or objects, correlates requests and 
responses, and guarantees proper block sequencing. 
Object/communications manager interface 443 interacts with other 
native code modules as follows: object/communications manager 443 (1) 
* receives all RS 400 object requests from object storage facility 439, 

3 and forwards objects received from network 10 via link communications 
manager 444 directly to the requesting modules; (2) receives ad list 
requests from ad manager 442, which thereafter periodically calls 
object/communications manager 443 to receive ad list responses; (3) 
receives data collection messages and send requests from data 

> collection manager 441; (4) receives application-level requests from 
TBOL interpreter 438, which also periodically calls 
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object/communications manager interface 443 to receive responses (if 
required) ; and (5) receives and sends DIA formatted objects and 
messages from and to link communications manager 444. 

Object/communications manager interface 443 sends and receives 
5 DIA formatted messages on behalf of TBOL interpreter 438 and sends 
object requests and receives objects on behalf of object storage 
facility 439. Communication packets received containing parts of 
requested objects are passed to object storage facility 439 which 
assembles the packets into the object before storing it. If the 

10 object was requested by object interpreter 435, all packets received 
by object storage facility 439 are also passed to object interpreter 
435 avoiding the delay required to receive an entire object before 
processing the object. Objects which are pre-f etched are stored by 
object storage facility 439. 

15 Messages sent to interactive network 10 are directed via DIA to 

applications in network 10. Messages may include transaction requests 
for accords or additional processing of records or may include records 
from£ja partitioned application program object or data collection 
manager 441. Messages to be received from network 10 usually comprise 

20 reco^s requested in a previous message sent to network 10. Requests 
received from object storage facility 439 include requests for objects 
from.=sStorage in interactive system 10. Responses to object requests 
contain either the requested object or an error code indicating an 
erroif condition, 

25 Object/communications manager 443 is normally the exclusive 

native code module to interface with link communications manager 444 
(except in the rare instance of a fatal error) . Link communications 
manager 444 controls the connecting and disconnecting of the telephone 
line, telephone dialing, and communications link data protocol. Link 

50 communications manager 444 accesses network 10 by means of a 
communications medium (not shown) link communications manager 444, 
which is responsible for a dial-up link on the public switched 
telephone network (PSTN) . Alternatively, other communications means, 
such as cable television or broadcast media, may be used. Link 
5 communications manager 444 interfaces with TBOL interpreter for 
connect and disconnect, and with interactive network 10 for send and 
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receive. 

Link communications manager 444 is subdivided into modem control 
and protocol handler units. Modem control (a software function well 
known to the art) hands the modem specific handshaking that occurs 

5 during connect and disconnect. Protocol handler is responsible for 
transmission and receipt of data packets using the TCS (TRINTEX 
Communications Subsystem) protocol (which is a variety of OSI link 
level protocol, also well known to the art). 

Fatal error manager 469 is invoked by all reception system 

.0 components upon the occurrence of any condition which precludes 
recovery. Fatal error manager 469 displays a screen to the user with 
a textual message and an error code through display manager 461. 
Fatal error manager 469 sends an error report message through the link 
communications manager 444 to a subsystem of interactive network 10. 

.5 "Ehe source code for the reception system software as noted above 

is described in parent application serial number 388,156 filed July 
28, 1|H39, now issued as U.S. patent <^S^7 the contents of which 

are ifiborporated herein by reference. 

' was** 

■V} sAmple application 

0 Page 255 illustrated irtsFIG. 3b corresponds to a partitioned 

application that permit's a usek to purchase apples. It shows how the 
monit&r screen 414 of the recep\ion system 400 might appear to the 
user.>! Displayed page 255 includes a number of page partitions and 
corresponding page elements. \ 

5 The page template object (PTO)\ 500 representing page 255 is 

illustrated in FIG. 9.. PTO 500 defined the composition of the page, 
including header 250, body 260, display fields 270, 271, 272, 
advertising 280, and command bar 290. Page\element objects (PEOs) 504 
are associated with page partitions numbered; e.g., 250, 260, 280. 

0 They respectively, present information in the Header 250, identifying 
the page topic as ABC APPLES; in the body 260,\ldentifying the cost 
of apples; and prompt the user to input into fields within body 260 
the desired number of apples to be ordered. In ^advertising 280, 
presentation data and a field representing a post-proctessor that will 

5 cause the user to navigate to a targetable advertising, \s presented. 
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In FIG. 9, tHe structure of PTO 500 can be traced. PTO 500 
contains a page fomnat call segment 52 6, which calls page format 
object (PFO) 502 . \ PFO 502 describes the location and size of 
partitions on the pagte and numbers assigned to each partition. The 
partition number is used in page element call segments 522 so that an 
association is established between a called page element object (PEO) 
504 and the page partition where it is to be displayed. Programs 
attached to this PEO can be executed only when the cursor is in the 
page partition designated within the PEO. 

PTO 500 contains two page element call segments 522, which 
reference the PEOs 504 for partitions 250 and 260. Each PEO 504 
defines the contents of the partition. The header in partition 250 
has only a presentation data segment 530 in its PEO 504. No input, 
action, or display fields are associated with that partition. 

3?he PEO 504 for partition 260 contains a presentation data 
segment 530 and field definition segments 516 for the three fields 
that ;3re defined in that partition. Two of the fields will be used 
for display only. One field w\ll be used for input of user supplied 
data M[ 

/fn the example application^ the PEO 504 for body partition 260 
specifies that two program objects 508 are part of the body partition. 
The first program, shown in Display field 270, 271, 272, is called an 
initializer and is invoked unconditionally by TBOL interpreter 438 
concurrently with the display of presentation data for the partition. 
In thsjs application, the function o$ the initializer is represented 
by the following pseudo-code: 

1. Move default values to input\and display fields; 

2. "SEND" a transaction to tne apple application that is 
resident on interactive system 10; 

3. "RECEIVE" the result from interactive system 10; i.e. the 
current price of an apple; 

4. Move the price of an apple to PEy 271 so that it will be 
displayed; 

5. Position the cursor on the input fi)?ld; and 

6. Terminate execution of this logic. 
The second program object 508 is a field po^t-processor . It will 
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be invoked conditionally, depending upon the user keystroke input. 
In this example, it will be invoked if the user changes the input 
field contents\by entering a number. The pseudo code for this post- 
processor is asNfollows: 

1. Use the value in PEV 270 (the value associated with the data 
entered by the useir into the second input data field 270) to be the 
number of apples ordered. 

2. Multiply thte number of apples ordered times the cost per 
apple previously obtained by the initializer; 

3. Construct a string that contains the message "THE COST OF THE 
APPLES YOU ORDERED IS $4^5.34;"; 

4. Move the string\ into PEV 272 so that the result will be 
displayed for the user? ana 

5. Terminate execution of this logic. 

The process by which the "APPLES" application is displayed, 
initiiaLized, and run is as follows. 

jPhe "APPLES" application is initiated when the user navigates 
from |phe previous partitioned application, with the navigation target 
beingjhe object id of the "APPLES" PTO 500 (that is, object id ABC1) . 
This event causes keyboard managen 434 to pass the PTO object id, ABC1 
(whic|f may, for example, have been called by the keyword navigation 
segmejrat 520 within a PEO 504 of the previous partitioned application) , 
to object interpreter 435. With reference to the RS application 
protocol depicted in FIG. 6, when Vthe partitioned application is 
initialed, RS 400 enters the Process Object state (B) using transition 
(1) . Object interpreter 4 35 then sends a synchronous request for the 
PTO 500 specified in the navigation event to object storage facility 
439. Object storage facility 439 attempts to acquire the requested 
object from local store 440 or from delivery system 20 by means of 
object/communication manager 443, and returns an error code if the 
object cannot be acquired. \ 

Once the PTO 500 is acquired by objeot/communications manager 
443, object interpreter 435 begins to build\pPT by parsing PTO 500 
into its constituent segment calls to pages\and page elements, as 
shown in FIG. 4d and interpreting such segments. PFO and PEO call 
segments 526 and 522 require the acquisition \>f the corresponding 



objects with obMect id's <ABCF>, <ABCX> and <ABCY>. Parsing and 
interpretation ofK object ABCY requires the further acquisition of 
program objects <ABCI> and <ABCJ>. 

During the interpretation of the PEOs 504 for partitions 250 and 
260, other RS 400 \events are triggered. This corresponds to 
transition (2) to interpret pre-processors state (C) in FIG. 6. 
Presentation data 530 is sent to display manager 461 for display using 
a NAPLPS decoder withinV display manager 461, and, as the PEO <ABCY> 
for partition 260 is parsed and interpreted by object interpreter 435, 
parameters in program carl segment 532 identify the program object 
<ABCI> as an initializer. Object interpreter 435 obtains the program 
object from object storage racility 439, and makes a request to TB0L 
interpreter 438 to execute the initializer program object 508 <ABCI>. 
The initializer performs the operations specified above using 
facilities of the RS virtual machine. TBOL interpreter 438, using 
operating environment 450, exeautes initializer program object 506 
<ABCI^, and may, if a further program object 508 is required in the 
execution of the initializer, make a synchronous application level 
obj ecfe. request to object storage facility 439. When the initializer 
termiit&tes ; control is returned to\object interpreter 435, shown as 
the return path in transition (2) iA FIG. 6. 

Having returned to the process object state (B) , object processor 
435 continues processing the objects associated with PTO <ABC1>. 
Ob j ectp interpreter continues to construct the PPT, providing RS 400 
with aft environment for subsequent processing of the PTO <ABC1> by 
pre-processors and post-processors at the. page, partition, and field 
levels. When the PPT has been constructed and the initializer 
executed, control is returned to key boar d\ manager 434, and the RS 
enters the wait for event (E) State, via transition (4), as shown in 
FIG. 6. \ 

In the wait for event state, the partitioned application waits 
for the user to create an event. In any partitioned application, the 
user has many options. For example, the user may move the cursor to 
the "JUMP" field 296 on the command bar 290, which is outside the 
current application, and thus cause subsequent navigation to another 
application. For purposes of this example, it is ^assumed that the 



user enters the number of apples he wishes to order by entering a 
digit in display fieM 271. 

Keyboard manager 434 translates the input from the user's 
keyboard to a logical representation independent of any type of 

5 personal computer. Keyboard manager 434 saves the data entered by the 
user in a buffer associated with the current field defined by the 
location of the cursor. \ The buffer is indexed by its PEV number, 
which is the same as they field number assigned to it during the 
formation of the page element. Keyboard manager 434 determines for 
10 each keystroke whether the keystroke corresponds to an input event or 
to an action or completion event. Input events are logical keystrokes 
and are sent by keyboard manager to display manager 461, which 
displays the data at the inpuA field location. Display manager 461 
also has access to the field buffer as indexed by its PEV number. 
L5 The input data are available to TBOL interpreter 438 for 

subsequent processing. When the cursor is in a partition, only the 
PEVs 'lor that partition are accessible to the RS virtual machine. 
Aftertfthe input from the user is Complete (as indicated by a user 
actioiE! such as pressing the RETURN key or entry of data into a field 

0 with action attribute) , RS 400 enters the Process Event state (E) 
via transition (4) . \ 

!£or purposes of this example, let us assume that the user enters 
the df§it "5" in input field 270. A transition is made to the process 
event ji.tate (E) . Keyboard manager 434 and\display manager 437 perform 

5 a number of actions, such as the display of the keystroke on the 
screeff; the collection of the keystroke for input, and optionally, the 
validation of the keystroke, i.e. numeric input only in numeric 
fields. When the keystroke is processed, a return is made to the wait 
for event state (D) . Edit attributes are specified in the field 

) definition segment. \ 

Suppose the user inputs a "6" next. A transition occurs to the 
PE state and after the "6" is processed, the WaiV for Event (D) state 
is reentered. If the user hits the "completion" Vey (e.g., ENTER) the 
Process Event (E) state will be entered. Th© action attributes 
associated with field 272 identify this as a system event to trigger 
post-processor program object <ABCJ>. When the interpretive execution 



of program object <AkCJ> is complete the wait for event state (D) 
will again be entered. \TK|?\user is then free to enter another value 
in the input field, or s^ect a command bar function and exit the 
apples application. ^ 

While this invention has been described in its preferred form, 
it will be appreciated that changes may be made in the form, 
construction, procedure and arrangement of its various elements and 
steps without departing -from its spirit or scope. 



What we claim is: 

X ^J^/ /// ^ la Metho< Kfor storing data in a computer network, the network 
26^ including a multiplicity of user reception systems at which respective 

3 users can requestVapplications during user sessions, the application 

4, being generated friam the data, the method comprising the steps of: 

5 a, establishing data stores within the network from which 

6 - data may be obtained fdr generating the applications during data usage 

7 sessions; \ 

8 b* associating storage control parameters with the data to 

9 be stored; \^ 

10 c. supplying data tb> the respective stores for use in 
.1 generating applications; and 

■ 2 d - retaining data at the\stores based on the respective 

.3 storagje control parameters. \ 

1 The method of claim 1 wherein associating storage control 

2 parameters with the data includes providing a data identification 

3 parameter. 

1 3. The method of claim 2 wherein establishing the date stores 

2 includes providing the respective stores with a prescribed capacity, 

3 and supplying data to the stores includes supplying data in excess of 

4 capacdjfey and deleting data on a least-recently-used basis such that 

5 retailing data at the respective stores may be determined by the 

6 control parameters and by data usage experience. 

1 4. The method of claim 3 wherein associating storage control 

2 parameters with the data includes providing a data storage candidacy 

3 parameter in addition to the data identification parameter, and 

4 wherein retaining data at the respective stores may be determined by 

5 respective data storage candidacy parameter and the data usage 
5 experience . 
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1 5. The method of claim 4 wherein establishing the data stores 

2 includes providing first store portions for maintaining data during 

3 respective data usage sessions and providing second store portions for 

4 maintaining data during and between respective data usage session, 

1. .6. The method of claim 5 wherein establishing the data stores 

2 includes providing first store portions as a temporary cache, and 

3 - providing the second store portion as a fixed stage, 

1 7. The method of claim 6 wherein establishing the data stores 

2 includes providing the respective temporary caches as file element in 

3 a volatile memory element, and providing the respective fixed stages 

4 as file elements in a nonvolatile memory element. 

1 8. The method of claim 5 wherein associating storage control 

2 parameters with the data includes providing the storage candidacy 

3 parameter with a range of values. 

1 Jf> The method of claim 8 wherein providing the storage candidacy 

2 parameter with a range of values includes providing lower storage 

3 candi§fjacy parameter values dependent on data sensitive to time. 

1 1.0. The method of claim 9 wherein associating storage control 

2 parameters with the data further includes providing a version control 

3 parameter that indicates data currency. 

'war 

1 11. The method of claim 10 wherein associating storage control 

2 parameters with the data includes providing the candidacy parameter 

3 with a range that includes a value which prevents the data from being 

4 stored. 

1 12. The method of claim 10 wherein associating storage control 

2 parameters with the data includes providing the storage candidacy 

3 parameter with a range that includes a value which permits the data 

4 to be stored only during data usage session. 
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1 13. The method of claim 10 wherein associating storage control 

2 parameters with the data includes providing the storage candidacy 

3 parameter with a range that includes a value which permits the data 

4 to be stored between respective usage sessions. 

1 14. The method of claim 13 wherein retaining data at the stores 

2 based on the respective storage control parameters includes retaining 

3 ; the data between data usage sessions independent of the most-recent ly- 

4 used deletion condition. 

5 15. The method of claim 1 wherein establishing data stores at the 

6 respective reception systems includes setting the stores respective 

7 capacities dependent on the respective reception system storage 

8 capacity and the currency requirements of the data. 

1 JS. Method for storing data in a computer network, the network 

2 including a multiplicity of user reception systems at which respective 

3 usersjcan request applications during user sessions, the application 

4 - being ^genera ted from the data, the method comprising the steps of: 

5 l75 a - establishing data stores of prescribed capacities at the 

6 respective reception systems, the stores including first portions 

7 maintained during respective user sessions and second portion 

8 maintained during and between respective user sessions; 

9 3^ b. associating storage control parameters with the data to 

0 be stcSred; 

1 c. supplying data to the stores for use at the respective 

2 reception systems in excess of the store capacity and deleting data 

3 from the stores on a least-recently-used basis such that the data 

4 retained at the stores between respective user sessions will be 

5 determined by the storage control parameters of the data and the usage 

6 experience at the respective reception systems. 

1 17. The method of claim 16 wherein establishing the data stores 

2 includes providing the first store portions as caches and the second 

3 store portions as stages. 

si 



1 18. The method of claim 17 wherein establishing the data stores 

2 includes providing the store caches in volatile memory and the store 

3 stages in nonvolatile memory. 

1 19. The method of claim 18 wherein associating storage control 

2 , parameters with the data includes providing the storage candidacy 

3 parameter with a range of values. 

1 20. The method of claim 19 wherein associating storage control 

2 parameters with the data further includes providing a version control 

3 parameter that indicates data currency. 
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ABSTRACT 



A method for storing data in an interactive computer network is 
described. In preferred form, the method features steps for 
establishing data stores of prescribed capacities within a network for 
delivering an interactive service. The stored data is used in 
presenting the applications that makeup the service. The method 
features steps for associating storage control parameters with the 
application data to be stored and supplying data to the respective 
stores in excess of their respective capacities. The method includes 
steps for retaining data at the stores based on the respective 
prescribed storage control parameters and the date usage experience 
at the respective stores. In preferred form, the method features 
steps jfor providing the data stores with a temporary cache for storing 
data 4«ring a data use session and a variable-content, permanent, file 
for retaining data between data use sessions. The method configures 
the cajhe from available RAM and a prescribed disk file, and the stage 
from aWjcontent-variable, permanent disk file. Data is retained at the 
cache ^and subsequently at the stage based on control parameters 
associated with the data identification, storage candidacy and 
versi^, as combined with a least-recently-used criterion. 
Accordingly, over multiple use sessions, the stage self -configures 
with dSta tailored to use experience. Also in the preferred form of 
the method described, the data is arranged as objects having a header 
including the storage control parameters. 
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